Почему не ZFS?

Что: fd06c1c180f30fb802075a3a4a48ef0197576a85

Когда: 2022-02-04 16:58:40+03:00

Темы: hate zfs

Почему не ZFS?

https://storytime.ivysaur.me/posts/why-not-zfs/

  Да и пофиг. Это их проблемы. У них и так оно плохо интегрировано и ARC
  не дружит с остальной системой кэширования.

  Ну тут нечего мне сказать. Как в Linux не знаю. В FreeBSD используется
  родная crypto подсистема. Само по себе родное шифрование ZFS не всем
  подойдёт, потому что там много чего не зашифровано на самом деле и
  полнодисковое может быть предпочтительнее.

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

  Да, всё так. Как и делать shrink массивов. Есть ограничения. Волнуют
  ли оно большинство? Вряд ли. Ибо shrink я считаю глупостью считать
  недостатком.

  Куча статей на эту тему. Нет, не медленный. И не быстрый. Много от
  чего зависит его производительность. RAIDZ с 4-8 KiB блоками вообще
  будет иметь overhead потерянного места больший чем было бы в зеркале.

  Ага, только с возможностью потерять данные при аварии. Write-hole
  никто не отменял. Даст ли mdadm с диском для хранения промежуточного
  state для write-hole safety больше IOPS? Все молчат.

  scrub, rebuild последовательное чтение/запись быстрее
  Нет. Зависит от степени заполненности массива. Если у меня вылетел
  диск из pool-а с 1 GiB полезных данных, то resilver потребует
  чтение/запись (пускай и с random IO) только гигабайта данных. В
  обычном же RAID из-за кратковременного сбоя контакта -- потребуется
  чтение/запись всех 2 TB данных для 2 TB диска. Кроме того, алгоритмы
  scrub/resilver улучшаются со временем и scrub уже вроде бы не первый
  год старается всё делать последовательно. Это почти полностью лживый
  аргумент.

  У меня зачастую наоборот. А phoronix умудряется чисто CPU bound задачи
  сделать так, что на одном и том же процессоре может отличаться в разы
  время работы компрессора (6d986bf15a3e11ffd3d82f0f7b74b9f7af566ab0).
  Ну и как бы какой смысл сравнивать ext4 и ZFS, у которых кардинально
  разные возможности и гарантии целостности/консистентности. Кого
  волнует производительность, если данные/ФС можно потерять незаметно?

  Верно. У всего своя цена. ZFS -- дорогая штука. И всё зависит от
  режимов работы с массивом -- линейно записать для хранения фильмы и их
  потом линейно читать, редко удаляя или перезаписывая -- тут никаких
  проблем с производительностью не будет. Это CoW система -- у неё есть
  своя цена.

  Violation это когда что-то явно подразумевалось, но оно нарушается. Не
  нужно делать ложных непойми откуда взявшихся ожиданий от ZFS. Поверх
  LVM/whatever ZFS можно использовать. Использовать менеджеры томов
  поверх ZFS ZVOL-ов -- тоже. Отсутствие разделения знаний о блочном
  устройстве и файлов/объектов на нём -- даёт колоссальные преимущества,
  невозможные иначе.

  И?

  Я не понимаю: много относительно чего? Очевидно что для дедупликации
  нужно иметь какую-то табличку с хэшами всех блоков и ходить по ней
  постоянно чтобы проверять нет ли такого блока на диске уже. ZFS
  неэкономно расходует место под эту табличку? Нет, overhead
  незначительный, почти всё отдаётся под настоящий payload всех этих
  хэшей и ссылок. Если не хватает RAM и можно потерпеть просадку по IO,
  то без проблем можно использовать L2ARC для выгрузки таблицы
  дедупликации. Совершенно бредовый аргумент. Сжатие использует больше
  CPU. Очевидно! Не нравится -- отключи сжатие. Дедупликация использует
  больше памяти. Очевидно! Не нравится -- отключи. Хранит таблицы ZFS
  достаточно экономно с маленьким overhead-ом

  Да. Это просто, надёжно и имеет предсказуемое поведение. Асинхронный
  фоновый процесс btrfs... означает что не понятно когда как и что у
  меня будет дедуплицировано. Если я делаю nncp-reass сборку файла, то я
  не хочу чтобы на диск что-то вообще было записано, ибо я знаю что это
  полностью дуплицированные блоки, которые в btrfs могли бы означать
  запись на диск и дикую просадку по производительности.

  Ну тут проблемы только Linux. В нём page cache и ARC живут
  параллельной жизнью. Если кроме ZFS на хосте ничего нет, то проблем не
  будет -- всё так. В противном случае можно ждать неприятного (или
  памяти не на ARC будет не хватать, либо ARC не будет использовать все
  возможности памяти). Двойной mmap -- да, это проявится не только на
  Linux. Наверняка mmap-heavy задачи заранее известны и серверу можно
  сделать соответствующий tuning.

  Ну я бы тут приводил подоб��ое в пример, ибо даже для ext*fs, UFS*
  файловых систем, которые на порядки проще, порядки меньше всего умеют,
  до сих пор есть баги и находятся критично важные проблемы. Вот btrfs
  до сих пор не стабильна достаточно чтобы не ссать и использовать её не
  боясь всё потерять. ZFS давно стабильна. Ошибки находят в любом софте,
  даже очень старом и проверенном временем, даже очень простом.

  Так и не понял что он должен делать то, кроме того что ZFS и так
  делает при импорте pool-а или при scrub. Автор считает что
  журналируемая ext4 точно так же консистентна должна быть, как и
  copy-on-write системы. Я точно не знаю про ext4, но чую что там не
  сильно всё отличается от UFS/FFS подходов с журналами и soft-updates,
  где журнал спасает/помогает только для ряда транзакций действий.
  Например soft-updates не позволит жутко испортить иноды, но место при
  этом может спокойно "утечь" -- таблица/bitmap свободных блоков это
  отдельная тема. Поэтому там всё равно есть отдельно fsck. Хочется
  проверить все хэши -- делай scrub или zfs send, в чём проблема?

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


  незнания что за объекты обслуживаются в блоках.

  против, ибо где-то это разумнее может быть, точно безопаснее.

  при этом сделать для любой ФС консистентную выгрузку состояния. И
  overhead от количества передаваемых данных на которые никто не
  ссылается (пустое место). И умалчивает про инкрементальные снимки. И
  как бы их сделать эффективно.

  чем проверять то их целостность? Он говорит про 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 оптимизации.

  Про 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, восстанавливая побитые данные (проверено!), тогда
как в предложениях автора ничего для этого случая нет.

оставить комментарий

Сгенерирован: SGBlog 0.34.0