EXT4 vs ZFS

Дефрагментатор есть?

Нет и никогда не будет (я серьёзно). При заполнении тома производительность деградирует серьёзно. Имей в виду.

zfs=FreeBSD

До этого юзал ext4 в режиме data=journal.

ненужно. купи упс

на что обратить внимание?

На неумение менять количество дисков в raidz(2,3). Надо расширить пул — разрушай vdev или добавляй новый. Надо убрать диск — круши-ломай. Это, пожалуй, самый важный фактор для домашних файлопомоек.

Как у zfs сейчас со стабильностью на GNU/Linux?

stable as rock

Дефрагментатор есть?

Нет, и не нужен, в силу архитектуры ФС.

Я не очень в теме zfs, она сразу данные линейно что ли пишет, или как ещё возможно решить проблему фрагментации?

не очень в теме zfs, она сразу данные линейно что ли пишет

А ты на одном диске её собрался использовать? Если речь о массивах raid-z(1,2,3), то говорить о фрагментации вообще не имеет смысла, там всё хорошо. ZfS на одном диске не пробовал.

как ещё возможно решить проблему фрагментации?

Учитывать только занятые блоки 128k легче, чем 4k-блоки, даже если используется хранение данных в inode, гораздо легче (в 32 раза).

Какая разница? На винте случайное чтение мшновенным от этого не становится.

А ты на одном диске её собрался использовать

Я нет, а вот ОП да.

Разница большая - блоки ФС ведь не дробятся на составляющие, а значит чем больше блок, тем меньше блоков содержится в наугад выбранном файле, тем меньше перемещений головки, чтобы его «собрать» и предоставить пользователю. Следовательно - меньше фрагментация данных.

Но один хрен оно есть. И современные диски огромны.

Тогда все сосут у fat.

У FAT размер кластера от 512 байт до 32k байт.

Фрагментация менее (в 32 раза) выражена.

Так по твоей логике это помогает бороться с фрагментацией.

Некорректное заявление. Сравни 4к на 1т и 128к на 16т.

Большинство использует ext4.

Почему это? На любом томе независимо от размера разброс кластеров 4k при перезаписи файлов будет всегда выше разброса кластеров 128k, потому что в мелких всегда больше в одном и том же занятом объёме.

Но фрагментация никуда не денется. Не? А почему не пилят средства борьбы с ней?

А почему не пилят средства борьбы с ней?

Будущее за SSD ведь, а там дефрагментация никак не сказывается.

До него ещё далеко. А зфс не пионерия.

Насколько я понимаю, zfs последовательное чтение «пробрасывает» сразу на диски. Фрагментированное, может держать в кешах (RAM + SSD).

Вот статистика попадания в кеш чтения с одного из серверов на zfs:

• 36.45% - запросов было удовлетворено из кеша ОЗУ
• 23.71% - запросов из кеша SSD

Вот с другого:

• 85.68% - ОЗУ
• 56.97% - SSD

Это при том, что у меня 40гб. кеша на ssd, 5гб кеша в ОЗУ. Как по мне, это весьма годный результат. С тем учётом, что у меня sync запись проходит через ssd (zlog), это ещё даёт мне прирост на СУБД. В общем как по мне: норм!

Зависит от конфигурации, в общем случае, если это не синхроная операция без zil, то да, пишет линейно группами транзакций.

Здесь свежий список фиксов Ext4

У ext4 фиксированные иноды, что для файлопомойки не лучший вариант, может перестать писать при наличии места

Сейчас при настройках по умолчанию там такие запасы, что даже урезать часто хочется.

У ext4 фиксированные иноды, что для файлопомойки не лучший вариант, может перестать писать при наличии места

Файлопомойка должна быть действительно помойкой, чтобы исчерпать иноды хотя бы на 500 гб диске.

Для однодискового страйпа рекомендую btrfs поставить. Scrub есть, снапшоты есть, lzo-сжатие есть. Очень даже надежен, если не пытаться сделать RAID5/6. ext4 суперстабилен, но чисто теоретически, если у тебя начнет умирать планка памяти ничто не спасет их целостность.

ZFS

ZFS под линуксом у меня используется только полгода, так что я не буду делать никаких заявлений о стабильности.

всем спасибо, я решил что конкретно для этой моей задачи я пока буду продолжать юзать ext4 в режиме data=journal.

lzo-сжатие

Там же zstd есть уже. Ждём, когда можно будет указывать уровень. Особенно в свойствах объектов (btrfs property set /file compression zlib:9).

Только недавно пролетал здесь тред «ололо памагите екст4 отдала концы». Как видишь все хорошо, продолжай её использовать.

если у тебя начнет умирать планка памяти ничто не спасет их целостность.

От повреждения данных в RAM ZFS и btrfs не помогают, снимут контрольную сумму с поврежденных данных и запишут на диск, если не хочешь страдать от такого то надо ставить ECC RAM.

Нет, и не нужен, в силу архитектуры ФС.

Че ?

Че ?

Пробел между предложением и знаком препинания не позволяет тебе понять.

Пробел между предложением и знаком препинания не позволяет тебе понять.

Ну расскажи мне убогому, каким волшебным образом в zfs отсутствует фрагментация, о великий гуру грамматики.

==RIP

Ты наркоман что ли? С чего ты это взял?

снимут контрольную сумму с поврежденных данных и запишут на диск

Фрагментация там by design, просто zfs-фанбои утверждают, что в zfs настолько умные алгоритмы, что фрагментация как бы есть, но всё-таки её как бы нет. Что, конечно, бред полный, zfs от тормозов спасает только жирный кэш, да и то не особо.

Я это знаю :)

снимут контрольную сумму с поврежденных данных и запишут на диск

Ты наркоман что ли? С чего ты это взял?

А ты наркоман?

Обсуждение было в контексте гибнущей планки RAM. И ZFS и btrfs хранят в памяти только один экземпляр данных, расчет контрольной суммы отложен до момента сразу перед записью на диски.

Данные дублируются только на накопителях, соотв. если данные повредятся до вычисления контрольных сумм то суммы будут сняты с поврежденных данных и всё будет записано на диски в N экземплярах, в зависимости от того какую избыточность настроил администратор машины.

каким волшебным образом в zfs отсутствует фрагментация

А расскажи мне о понятии фрагментации на, например, 10-ти дисковом массиве raidz2 и о её влиянии на производительность? Также есть, не дураками придуманные, штуки, такие как arc в ОЗУ, l2arc и zil на ssd, которые даже на однодисковом сторадже сводят на нет влияние фрагментации на производительность.

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

Ты мне лучше на первый вопрос ответь про массив, без всяких костылей и подпорок.

даже на однодисковом сторадже сводят на нет влияние фрагментации на производительность

Конечно же, это чушь фанбойская. Как только весь кэш забивается, и нужно сделать что-то с данными, которых нет в кэше, то начинается тормозилово. Например, 40 секунд открывать каталог с парой тысяч файлов - норма для zfs.

Например, 40 секунд открывать каталог с парой тысяч файлов - норма для zfs.

Брехня, у меня есть каталоги с миллионами файлов, открываются быстро, даже если не в кэше.

https://cs8.pikabu.ru/post_img/big/2016/02/29/6/145673352818127463.jpg

Да при чем тут массив? Давай ещё фрагментацию на ssd обсудим? Ты выше сказал, что фрагментации в zfs нет и тут же называешь методы борьбы с ней. Ещё раз тебя спрашиваю, так есть фрагментация в zfs или нет? А потом уж обсудим массив.

Ну как это «нет»? Исходя из описанных выше механизмов - невозможно, чтоб ее совсем не было.

Ну мой оппонент утверждает обратное :)