The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз OpenZFS 2.1 с поддержкой dRAID, opennews (??), 03-Июл-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


3. "Релиз OpenZFS 2.1 с поддержкой dRAID"  –6 +/
Сообщение от Аноним (3), 03-Июл-21, 00:25 
Дефрагментацию так и не запилили? Тогда не нужно.
Ответить | Правка | Наверх | Cообщить модератору

7. "Релиз OpenZFS 2.1 с поддержкой dRAID"  –2 +/
Сообщение от Аноним (7), 03-Июл-21, 01:46 
Зачем вам дефрагментатор? На zfs возможна лишь фрагментация свободного пространства, но не данных.
Ответить | Правка | Наверх | Cообщить модератору

86. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +3 +/
Сообщение от Онаним (?), 03-Июл-21, 09:11 
Это на коровах-то (CoW) "но не данных"?
Лечите кого-нибудь другого.
На коровах почти любая запись в файл фрагментирует данные by design.
Ответить | Правка | Наверх | Cообщить модератору

161. "Релиз OpenZFS 2.1 с поддержкой dRAID"  –5 +/
Сообщение от Аноним (161), 03-Июл-21, 15:44 
прямо "by design"? что, этот "design" запрещает копирование элемента целеком? насильственно заставляет делать это только для отдельной страницы? или все таки есть варианты?
Ответить | Правка | Наверх | Cообщить модератору

261. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от freehckemail (ok), 05-Июл-21, 17:19 
> На коровах почти любая запись в файл фрагментирует данные by design.

ARC в помощь.

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

278. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от Онаним (?), 20-Сен-21, 20:34 
И как наша доблестная жанночка решит проблему фрагментации на носителе?
Как раз причина, почему ZFS идёт нахер - если ему не отдать памяти по горло, он нормально работать не будет.
Ответить | Правка | Наверх | Cообщить модератору

279. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от freehckemail (ok), 22-Сен-21, 13:48 
Совсем не решит, но существенно облегчит дело за счёт сериализации данных перед сбросом.
А по поводу памяти -- ну так сначала надо выбрать ФС, удовлетворяющую вашим нуждам, а потом уже систему заказывать. К слову, рама стоит вообще копейки.
Ответить | Правка | Наверх | Cообщить модератору

280. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от Онаним (?), 22-Сен-21, 14:07 
Так собственно да, и это не ZFS :)
Ответить | Правка | Наверх | Cообщить модератору

276. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от Tim (??), 20-Сен-21, 16:52 
в zfs же RoW, а не CoW
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

277. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от Онаним (?), 20-Сен-21, 20:32 
FoW там. Fragment on Write или Fuckup on Write, как кому привычнее.
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

12. "Релиз OpenZFS 2.1 с поддержкой dRAID"  –1 +/
Сообщение от Хан (?), 03-Июл-21, 02:47 
Дефрагментация на HDD слишком тормозная и неэффективная, а на SSD вообще бессмысленная
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

71. "Релиз OpenZFS 2.1 с поддержкой dRAID"  –1 +/
Сообщение от bOOster (ok), 03-Июл-21, 07:47 
> Дефрагментацию так и не запилили? Тогда не нужно.

В высокоэффективных файловых структурах - система располагает данные для целевого назначения (максимальной производительности, минимального обьема и т.п.) и делает она это в соотвествии со своим порядком, а никак не твоим представлением, где и как должны лежать цельно-выровненные файлы...

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

87. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +1 +/
Сообщение от Онаним (?), 03-Июл-21, 09:12 
Ротационным накопителям пофиг на "свой порядок" у альтернативно одарённых, для них оптимальное расположение - последовательное.
Ответить | Правка | Наверх | Cообщить модератору

97. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +6 +/
Сообщение от пох. (?), 03-Июл-21, 09:35 
> Ротационным накопителям пофиг на "свой порядок" у альтернативно одарённых, для них оптимальное
> расположение - последовательное.

с разморозочкой, ваш MS-DOS давно уже немодно.

В многозадачной системе с множественным параллельным доступом к данным, причем как правило ни разу не linear, оно ни разу не будет оптимальным. Особенно с учетом того забавного факта, что у данных есть еще и метаданные, и их тоже надо читать каждый раз.

Оптимальным был бы хитрый interleave знающий точно о том что и какими кусками будет читаться, но за неимением /dev/astral - обходятся блоками разумной длинны и размещением метаданных немножко более разумным способом чем в твоем любимом fat.

Ответить | Правка | Наверх | Cообщить модератору

157. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от Аноним (157), 03-Июл-21, 15:04 
Ну и какими кусками твои DLL'ки читаются? Правильно. Целиком. Времена мсдос с 512к и оверлеями того, кончились.
Ответить | Правка | Наверх | Cообщить модератору

180. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +3 +/
Сообщение от пох. (?), 03-Июл-21, 22:28 
Какими попало они читаются. Ага, кончились.
Теперь кодовые страницы _mmap_аются. И читаются только при получении page fault (то есть неиспользуемые - вообще никогда). Там есть еще block size, prefetch и прочие фокусы, чтоб уж совсем по 4k не читать, но в целом мир устроен изрядно сложнее чем тебе кажется.

Впрочем, один раз записанный файл скорее всего уляжется на диск последовательно или около того - страдания секты свидетелей фрагментации начинаются когда файл переписывается на ходу. Для бинарников это немного странно.

Ответить | Правка | Наверх | Cообщить модератору

218. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от kai3341 (ok), 04-Июл-21, 13:04 
> страдания секты свидетелей фрагментации начинаются когда файл переписывается на ходу. Для бинарников это немного странно.

Кстати, это нормальный режим работы БД

Ответить | Правка | Наверх | Cообщить модератору

225. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от пох. (?), 04-Июл-21, 18:44 
без тебя мы бы об этом ну никак не догадались. Кстати, зачем тебе понадобилось подменять тему разговора?

Сколько процентов лично на твоем диске занимают какие-то там "биде" - 0.001 ?

Насколько часто им при этом нужен sequential доступ, даже если бы процент был целый один ?

Ответить | Правка | Наверх | Cообщить модератору

230. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от kai3341 (ok), 04-Июл-21, 22:27 
> без тебя мы бы об этом ну никак не догадались. Кстати, зачем
> тебе понадобилось подменять тему разговора?
> Сколько процентов лично на твоем диске занимают какие-то там "биде" - 0.001
> ?
> Насколько часто им при этом нужен sequential доступ, даже если бы процент
> был целый один ?

Ну и смысл было агриться? С тобой же никто не спорил.
Базочек у меня в наличии имеется. Процентов 10 займёт.
А вот чтобы последовательный доступ -- хз. Это, наверное, колоночное хранилище должно быть. У меня таких нет

Ответить | Правка | Наверх | Cообщить модератору

252. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от n00by (ok), 05-Июл-21, 10:18 
> когда файл переписывается
> на ходу. Для бинарников это немного странно.

Исполняемый файл не переписывается, его банально нельзя открыть с правами на запись и исполнение. Что бы запущенный экзешник возможно было переписать, Микрософт набангалорила удивительное по своим габаритам технологическое отверстие, через которое сливаются все права на файлы и проч.

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

251. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от n00by (ok), 05-Июл-21, 09:55 
> Ну и какими кусками твои DLL'ки читаются? Правильно. Целиком.

Вы удивитесь, но образы Portable Executable (dll в частности) в Вашей любимой Виндос вообще не читаются. Они _отображаются_. Сначала -- заголовок, потом -- релокации (если требуется) и импорт/экспорт. На этом всё. Далее сектора файла отображаются в страницы ОЗУ при доступе к командам/данным.

Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

88. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от Онаним (?), 03-Июл-21, 09:13 
Полноценным твердотельникам ещё более пофиг - у них внутри данные всё равно раскладываются так, как хотят они, а не софт.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

112. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от Аноним (112), 03-Июл-21, 11:22 
Да и в современных ЖД c LBA адресацией, соседние номера блоков часто не являются соседями физически. Скорей правила хорошего тона, чем жесткий закон, что надо хранить последовательно.
Ответить | Правка | Наверх | Cообщить модератору

175. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +/
Сообщение от Онаним (?), 03-Июл-21, 18:49 
Охохо.
Ладно, оставлю вас пребывать в уверенности, что LBA каждый сектор по диску рандомно размазывает.
Но если учесть, что единица чтения с диска - дорожка, в основном, нет, можно и индивидуальный сектор, но время чтения будет не сильно меньше... короче, оставлю.
Ответить | Правка | Наверх | Cообщить модератору

266. "Релиз OpenZFS 2.1 с поддержкой dRAID"  +1 +/
Сообщение от WD (?), 06-Июл-21, 19:03 
Шел 21 век, но почитатели LMR продолжали молиться своему старом богу. В то время как HMSMR контролится самим жестким диском. Фрагментация? Помолимся, братья...
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру