Почему не ZFS?

https://storytime.ivysaur.me/posts/why-not-zfs/
* ZFS не будет в ядре Linux
  Да и пофиг. Это их проблемы. У них и так оно плохо интегрировано и ARC
  не дружит с остальной системой кэширования.
* Низкая производительность шифрования.
  Ну тут нечего мне сказать. Как в Linux не знаю. В FreeBSD используется
  родная crypto подсистема. Само по себе родное шифрование ZFS не всем
  подойдёт, потому что там много чего не зашифровано на самом деле и
  полнодисковое может быть предпочтительнее.
* Не гибкий.
  Примеры надуманные. Даже если не хватает гибкости, то это не означает
  что для превалирующего большинства оно подходит без проблем.
* Нельзя добавлять/удалять диски из RAIDZ.
  Да, всё так. Как и делать shrink массивов. Есть ограничения. Волнуют
  ли оно большинство? Вряд ли. Ибо shrink я считаю глупостью считать
  недостатком.
* RAIDZ медленный
  Куча статей на эту тему. Нет, не медленный. И не быстрый. Много от
  чего зависит его производительность. RAIDZ с 4-8 KiB блоками вообще
  будет иметь overhead потерянного места больший чем было бы в зеркале.
* mdadm RAID6 даст больше IOPS
  Ага, только с возможностью потерять данные при аварии. Write-hole
  никто не отменял. Даст ли mdadm с диском для хранения промежуточного
  state для write-hole safety больше IOPS? Все молчат.
* Файло-ориентированный RAID медленный. Для операций типа resilvering,
  scrub, rebuild последовательное чтение/запись быстрее
  Нет. Зависит от степени заполненности массива. Если у меня вылетел
  диск из pool-а с 1 GiB полезных данных, то resilver потребует
  чтение/запись (пускай и с random IO) только гигабайта данных. В
  обычном же RAID из-за кратковременного сбоя контакта -- потребуется
  чтение/запись всех 2 TB данных для 2 TB диска. Кроме того, алгоритмы
  scrub/resilver улучшаются со временем и scrub уже вроде бы не первый
  год старается всё делать последовательно. Это почти полностью лживый
  аргумент.
* Real-world performance is slow
  У меня зачастую наоборот. А phoronix умудряется чисто CPU bound задачи
  сделать так, что на одном и том же процессоре может отличаться в разы
  время работы компрессора (6d986bf15a3e11ffd3d82f0f7b74b9f7af566ab0).
  Ну и как бы какой смысл сравнивать ext4 и ZFS, у которых кардинально
  разные возможности и гарантии целостности/консистентности. Кого
  волнует производительность, если данные/ФС можно потерять незаметно?
* Производительность падает при отсутствии свободного места
  Верно. У всего своя цена. ZFS -- дорогая штука. И всё зависит от
  режимов работы с массивом -- линейно записать для хранения фильмы и их
  потом линейно читать, редко удаляя или перезаписывая -- тут никаких
  проблем с производительностью не будет. Это CoW система -- у неё есть
  своя цена.
* Layering violation of volume management
  Violation это когда что-то явно подразумевалось, но оно нарушается. Не
  нужно делать ложных непойми откуда взявшихся ожиданий от ZFS. Поверх
  LVM/whatever ZFS можно использовать. Использовать менеджеры томов
  поверх ZFS ZVOL-ов -- тоже. Отсутствие разделения знаний о блочном
  устройстве и файлов/объектов на нём -- даёт колоссальные преимущества,
  невозможные иначе.
* Не поддерживает reflink?
  И?
* Много памяти нужно для дедупликации
  Я не понимаю: много относительно чего? Очевидно что для дедупликации
  нужно иметь какую-то табличку с хэшами всех блоков и ходить по ней
  постоянно чтобы проверять нет ли такого блока на диске уже. ZFS
  неэкономно расходует место под эту табличку? Нет, overhead
  незначительный, почти всё отдаётся под настоящий payload всех этих
  хэшей и ссылок. Если не хватает RAM и можно потерпеть просадку по IO,
  то без проблем можно использовать L2ARC для выгрузки таблицы
  дедупликации. Совершенно бредовый аргумент. Сжатие использует больше
  CPU. Очевидно! Не нравится -- отключи сжатие. Дедупликация использует
  больше памяти. Очевидно! Не нравится -- отключи. Хранит таблицы ZFS
  достаточно экономно с маленьким overhead-ом
* Дедупликация синхронна
  Да. Это просто, надёжно и имеет предсказуемое поведение. Асинхронный
  фоновый процесс btrfs... означает что не понятно когда как и что у
  меня будет дедуплицировано. Если я делаю nncp-reass сборку файла, то я
  не хочу чтобы на диск что-то вообще было записано, ибо я знаю что это
  полностью дуплицированные блоки, которые в btrfs могли бы означать
  запись на диск и дикую просадку по производительности.
* ARC жрёт много памяти
  Ну тут проблемы только Linux. В нём page cache и ARC живут
  параллельной жизнью. Если кроме ZFS на хосте ничего нет, то проблем не
  будет -- всё так. В противном случае можно ждать неприятного (или
  памяти не на ARC будет не хватать, либо ARC не будет использовать все
  возможности памяти). Двойной mmap -- да, это проявится не только на
  Linux. Наверняка mmap-heavy задачи заранее известны и серверу можно
  сделать соответствующий tuning.
* Buggy + ссылка на сотни задач в трэкере
  Ну я бы тут приводил подобное в пример, ибо даже для ext*fs, UFS*
  файловых систем, которые на порядки проще, порядки меньше всего умеют,
  до сих пор есть баги и находятся критично важные проблемы. Вот btrfs
  до сих пор не стабильна достаточно чтобы не ссать и использовать её не
  боясь всё потерять. ZFS давно стабильна. Ошибки находят в любом софте,
  даже очень старом и проверенном временем, даже очень простом.
* Нет fsck
  Так и не понял что он должен делать то, кроме того что ZFS и так
  делает при импорте pool-а или при scrub. Автор считает что
  журналируемая ext4 точно так же консистентна должна быть, как и
  copy-on-write системы. Я точно не знаю про ext4, но чую что там не
  сильно всё отличается от UFS/FFS подходов с журналами и soft-updates,
  где журнал спасает/помогает только для ряда транзакций действий.
  Например soft-updates не позволит жутко испортить иноды, но место при
  этом может спокойно "утечь" -- таблица/bitmap свободных блоков это
  отдельная тема. Поэтому там всё равно есть отдельно fsck. Хочется
  проверить все хэши -- делай scrub или zfs send, в чём проблема?

Автор предлагает альтернативы?

* RAID, LVM -- спасибо, но write-hole и жуткая неэффективность из-за
  незнания что за объекты обслуживаются в блоках.
* Шифрование делать на блочном уровне -- тут ничего не могу сказать
  против, ибо где-то это разумнее может быть, точно безопаснее.
* Снимки автор предлагает делать через LVM snapshot-ы... умалчивая как
  при этом сделать для любой ФС консистентную выгрузку состояния. И
  overhead от количества передаваемых данных на которые никто не
  ссылается (пустое место). И умалчивает про инкрементальные снимки. И
  как бы их сделать эффективно.
* Scrub предлагает делать просто чтением данных. Что-то я не пойму: а
  чем проверять то их целостность? Он говорит про URE (Unrecoverable
  Read Error), то есть когда диск не может отдать данные. Автор, scrub
  делается в первую очередь и для проверки bit-rot-а! Не для того чтобы
  понять что диск выходит из строя/сбоит, а для проверки целостности!
* Дедупликация не стоит того. В целом тут я согласен, что задач где она
  имеет смысл -- мало. Речь про то что лучше для VM -- не согласен, ибо
  для них надо использовать zfs clone. Но даже у меня на моей рабочей
  системе: zroot  dedupratio  1.12x -- очень ощутимая дедупликация
  $GOPATH-а
* Компрессия не стоит того. Ну это вообще бред сивой кобылы. Нет,
  конечно есть много задач где она не поможет безусловно. Только одно из
  первых от чего почти все пользователи ZFS тащатся -- как много места
  сжалось и какой профит для производительности (данных то с диском
  теперь меньше передавать!) оно даёт. Заявление про sparse databases
  говорит о полном непонимании copy-on-write природы. Sparse файлы на
  CoW не работают просто по природе CoW. Точнее работают, но profit не
  имеют никакого. Причём тут сжатие? Речь про то, что с выключенным
  сжатием sparse блоки могут оказаться на диске, а с сжатием даже не
  будут записаны? Автор явно не учитывает что при любом обновлении
  блока, sparse блок будет записан в другом месте диска, нивелируя
  *любые* sparse оптимизации.
* Контрольные суммы не стоят того, ибо мол SATA/диск и так имеют CRC.
  Про bit-rot автор как-будто не слышал. "Вы можете использовать
  dm-integrity" -- согласен. "или btrfs, которая автоматически это
  делает". Ага... как и ZFS, тоже автоматически из коробки!

Если сложить предложения: RAID, LVM2, cryptsetup, lvmsync, cron-ed cat,
lvmvdo/kvdo/dduper, dm-integrity, cron-ed cksfv... то станет понятно
настолько администратор задолбается это всё поддерживать. Это без учёта
того, что тут не решается куча других проблем (типа write-hole, компрессии
файлов, инкрементальных снимков). И даже эти то проблемы не решены до
конца, ибо .sfv файлы не будут в real-time проверятся. Кроме того ZFS
делает self-healing, восстанавливая побитые данные (проверено!), тогда
как в предложениях автора ничего для этого случая нет.