Согласен, такое сравнение всегда интересно, но очень важно подходить к нему с учётом всех особенностей каждой ФС, на примере ZFS требуется внимательно изучить особенности Copy-on-Write.
Мне нравится ваш ход мыслей! :)
По предложениям ответить не могу, т.к. в нутра этой части не лазил, но мы всегда открыты к предложениям! Если готовы — можете внести свои предложения в виде issue, или сразу пулл реквестом, помогу с любым вопросом в части оформления, а другие участники всегда подскажут по коду, сообщество очень доброжелательное.
Это только базовые цифры для минимального варианта реализации. Также там точно есть счётчик повторений, глубже копать не стал, но эти цифры уже дают понимание, что требования не такие уж и раздутые.
Причина такого большого block pointer кроется в самой идее ZFS, и от этого никуда не деться. По этому базовый блок 128кб, он позволяет уменьшить накладные расходы. Больше блок — меньше накладные расходы, но при чтении файла с размером больше блока придётся прочитать ещё 1 полный блок (где находится окончание файла).
Вы о выше упомянутых 20гб? Это очень завышенная оценка, FreeBSD даёт оценку в ~ 5 гб на 1тб. Тут прекрасно описан метод работы DDT, там же приводятся конкретные цифры — 320 байт на каждую запись (уникальный блок).
Вообще есть прекрасная возможность заранее получить точные цифры — у zdb есть возможность имитации дедупликации:
zdb -S название_пула
На выходе будет Total allocated blocks, перемножив его на 320 байт получим требуемое количество ОЗУ. Также там приводится коэффициент дедупликации.
Вот симуляция для моего пула (бекапы, /home, /, немного виртуалок, одним словом дедуплицировать особо нечего):
На мои 800гб корневого пула, вообще не оптимизированного для dedup (а также 230гб бекапов с размером блока 1МБ) он дал всего лишь коэффициент 1.18, при этом на DDT потребуется 10.8М*320=3456мб ОЗУ. Оракл не рекомендует включать дедупликацию при коэффициенте меньше 2, я с ними полностью согласен.
Дедупликация — это прекрасно, но практически бесплатное lz4 сжатие (а для большинства HDD оно только ускоряет) в случае неповторяющихся данных намного целесообразнее.
Да, уже год активно дорабатывается и шлифуется. При чём оно разрабатывается с учётом всех недостатков реализации от Oracle, а также позволит штатными send/recieve и scrub отправлять и проверять данные на целостность без ключа.
Будет ли более «производительная» дедупликация, я имею ввиду с меньшими требованиями к ресурсам, особенно оперативке?
В целом производительность будет улучшаться в следующем мажорном выпуске, но явных проблем с дедупликацией нет. Требование к ОЗУ связано напрямую с deduplication table (структура, в которой хранится соответствие контрольной суммы и блока), если DDT в неё не помещается, то будет ухудшение производительности.
Отдельно упомяну, что в бета-релизе проведена большая работа по оптимизации управления данными в ОЗУ (сокращённо ABD)
Что на счёт ssd-кеширования
ZIL выносит журнал на отдельный носитель, а L2ARC очень похож на bcache со своими особенностями. Вот отличная статья по этому поводу.
Отдельно стоит отметить, что в случае ZFS часто хватает просто добавить ОЗУ, ARC прекрасно борется с вымыванием кеша.
На своём десктопе использую 2 WD RED в виде mirror с 16гб ОЗУ, после прогрева кеша машина работает не хуже, чем с ZFS на бюджетном SSD.
Сам ZFS позволяет делать clone со снапшотов (в рамках понятий ZFS), скорее всего это не реализовано в веб-интерфейсе proxmox (он также не видит созданные мной вручную снапшоты).
Ну и экспериментально попробуйте подтвердить, что исправный накопитель при определенных условиях выдаст некорректные данные
CERN и Amazon точно с вами не согласны, и это только верхушка айсберга.
У ЦЕРН в этом отчёте также есть статистика по RAID5, которая наглядно показывает, почему он ненадёжен. Приведу цитату:
1.Disk errors
…
2.RAID 5 verification
…
Running the verify command for the RAID controller on 492 systems over 4
weeks resulted in the fix of ~300 block problems. The disk vendors claims about
one unrecoverable bit error in 10^14 bits read/written. The 492 systems correspond
to about 1.5 PB of disk space.
…
The first thing to notice is that the verify command stresses the disks 3 times more than the actual physics applications, by just running it once per week.
The second observation is the that we measured about 300 errors while from the mentioned BER (Bit Error Rate) and the usage one would expect about 850 errors. As the vendor BER numbers are normally on the ‘safe’ side the measurement is close to the expectation.
3.Memory errors
…
4.CASTOR data pool checksum verification All the previously mentioned error will of course result in the corruption of user data.
…
Вашу позицию по поводу BER я всё-таки не разделяю (предпочитаю быть параноиком), пожелаю лишь нам всем удачи и в дальнейшём отсутствии такой проблемы.
Вы скорее говорите о мелких проблемах, которые вызваны аварийным отключением питания.
Отключение питания вообще не страшно ZFS, она атомарна, недозаписанная информация будет потеряна, но она не приведёт к какой либо ошибке в структуре.
говоря о данных не забывайте, что речь может идти о повреждении самих структур ZFS и мало проку будет от самих проверок
Крах будет примерно одинаковым по последствиям на любой файловой системе.
Говоря о ZFS, стоит в первую очередь понимать, какие отличия у CoW ФС от классических. В случае ZFS даже при успешной записи новых метаданных старые метаданные не затираются в течении нескольких транзакций ZFS, что технически даёт возможность откатиться на последнее стабильное состояние (вот пример, как можно поступить при повреждении структуры).
При всём этом носитель должен быть изрядно поврежден, т.к. метаданные дублируются на разных частях.
Сразу уточню, что я говорю только о Linux и Unix мире, т.к. ваша статья была о нём, и в контексте надёжности.
В случае отказа HDD, например проблемы с буферным ОЗУ на его плате, в накопитель запишутся как и битые данные, так и битые контрольные суммы для этих данных. Т.е. совершенно не спасет.
И это естественно. Контрольная сумма (даже неверная) сработает при чтении, что спасёт от использования искажённых данных, а также спасёт от дальнейших потерь.То есть ZFS гарантирует в первую очередь проверку на корректность, такие данные в любом случае потеряны, если нет резервирования (а при использовании любого резервирования ZFS просто восстановит такой блок на проблемный носитель, хотя это является первым признаком возможного сбоя носителя в будущем).
случайно искажение данных по вине накопителя — это то, чего нужно опасаться меньше всего (если рассматривать систему в комплексе).
Но этот фактор нельзя просто отбрасывать, если данные всё-таки нам дороги (всё же производители не просто так предоставляют информацию о BER). Тут скорее идёт речь о балансе надёжности к стоимости/производительности.
наличие ZFS практически бесполезно при других ненадежных элементах системы
Только ZFS отреагирует на проблемы с оборудованием (речь про искажение информации), другие ФС будут работать уже с некорректными данными, т.к. контрольные суммы они не считают.
в случае аварии и повреждения ZFS для домашнего пользователя или малого офиса процедура восстановления данных будет существенно усложнена
Можете уточнить точный сценарий, при котором ZFS сложнее восстановить?
Предполагая, что значительная часть данных с диска сохранена, и резервирование не используется — ZFS перетягивается тем же dd на другой диск, проводится штатный scrub, который выявляет все проблемы с данными, а неповреждённые блоки будут и дальше прекрасно работать (а метаданные всегда дублируются в нескольких частях диска).
Также в контексте использования на десктопах у ZFS есть возможность дублировать все блоки несколько раз (параметр copies).
Невозможность примонтирования (т.е. полный крах ФС) в счёт не беру, т.к. в этом случае проблемы будут одинаковы для всех ФС. Но и в этом случае ZFS на шаг впереди за счёт CoW (copy on write) — фактически он позволяет откатиться до последней корректной транзакции на диск.
Естественно, что рядовой пользователь не знает, как восстановить данные с любой ФС. Я не предлагаю на каждый ноутбук с Windows прямо сейчас городить ZFS (жаль, что сейчас это и невозможно), но это не значит, что самый распространённый вариант = самый верный.
Шествие ZFS в мире Unix идёт семимильными шагами, он уже используется в *BSD, Solaris, а в Linux будет штатным через 1-2 года, т.к. наконец решены вопросы с лицензией, Debian уже включил его в штатный репозиторий Stretch. Я считаю, что есть множество случаев, когда его использование оправдано.
В случае же NAS для дома и малых офисов дополнительная надежность ZFS звучит как издёвка.
Именно в этом случае и не соглашусь, ZFS создавалась с упором на ненадёжность носителей, что прямо относится к недорогим HDD, взять хотя бы подсчёт контрольных сумм всех данных. В отличии от него, другие ФС отдадут то, что выдал HDD, без проверки.
И уж если мы заговорили о надёжности железа, то оно от ФС не зависит.
«родные» файловые системы для ОС в которой они используются. пример: MS Windows — NTFS
Извиняюсь, что не уточнил — в Linux, для Windows вариантов особо и нет :) Для Linux понятия родной ФС в вашем случае можно заменить на наиболее используемую, видимо это ext4.
Также интересно узнать, есть ли у вас какое-то мнение по поводу надёжности файловых систем, что лучше или хуже?
Поговорить можно, если без эмоций оценивать его недостатки и достоинства.
Извиняюсь за излишнюю эмоциональность, но это не отменяет явных недостатков raid5 на дисках большого объёма хотя бы из-за BER. Да, он работает, но при сбое вероятность потерь меня очень смущает.
После случая «падения» данной файловой системы
Я не утверждал, что она не падает, к сожалению всё может в какой-то момент дать сбой. Наоборот, как раз сторонники ZFS наиболее яро пропагандируют эту идею, в частности только они явно выделяют рекомендации по ECC памяти.
преимуществ данной файловой системы весьма не очевидны, например для домашних пользователей и малых офисов.
Не хочу спорить, лично для меня это вопрос из разряда «мыши плакали, кололись, но продолжали есть кактус». Я понимаю, что у каждой ФС свои плюсы.
Кстати, у вас уже был опыт восстановления ZFS?
Также очень интересно было бы узнать ваши предпочтения по ФС.
Всё верно, в таком случае используется snapshot, он позволяет создавать инкрементальные срезы хоть каждую минуту. Но сразу оговорюсь, что не стоит подменять им полноценный бекап на другую машину (а в таком случае снапшоты также прекрасно передаются по сети в инкрементальном режиме).
Вообще, после zfs я уже не представляю, как можно жить без снапшотов и хеширования данных. На моей машине настроено создание снапшота всей системы раз в 15 минут, и это никак не влияет ни на производительность, ни на простои (см. https://github.com/zfsonlinux/zfs-auto-snapshot )
Спасибо всем за поддержку, статье быть, и не одной:)
Кстати, а какое свежее ПО в вашем случае используете, которого нет в Jessie? Лично я тяну из backports только видеодрайвер (т.к. для skylake нужен свежий) и браузер.
Сейчас требуется около 5гб ОЗУ на 1 тб данных, они требуются только в момент записи.
Но вопрос удобства всё же поднимается — в OpenZFS уже появилась возможность исключать диски.
К сожалению, интеграция в кодовую базу ядра в ближайшее время точно не произойдёт.
Мне нравится ваш ход мыслей! :)
По предложениям ответить не могу, т.к. в нутра этой части не лазил, но мы всегда открыты к предложениям! Если готовы — можете внести свои предложения в виде issue, или сразу пулл реквестом, помогу с любым вопросом в части оформления, а другие участники всегда подскажут по коду, сообщество очень доброжелательное.
— используемый sha256 (ваш dataHash) = 32 байт
— block pointer (ваш blockID) (blkptr_t) = 128 байт
Это только базовые цифры для минимального варианта реализации. Также там точно есть счётчик повторений, глубже копать не стал, но эти цифры уже дают понимание, что требования не такие уж и раздутые.
Причина такого большого block pointer кроется в самой идее ZFS, и от этого никуда не деться. По этому базовый блок 128кб, он позволяет уменьшить накладные расходы. Больше блок — меньше накладные расходы, но при чтении файла с размером больше блока придётся прочитать ещё 1 полный блок (где находится окончание файла).
Вы о выше упомянутых 20гб? Это очень завышенная оценка, FreeBSD даёт оценку в ~ 5 гб на 1тб.
Тут прекрасно описан метод работы DDT, там же приводятся конкретные цифры — 320 байт на каждую запись (уникальный блок).
Вообще есть прекрасная возможность заранее получить точные цифры — у zdb есть возможность имитации дедупликации:
На выходе будет Total allocated blocks, перемножив его на 320 байт получим требуемое количество ОЗУ. Также там приводится коэффициент дедупликации.
Вот симуляция для моего пула (бекапы, /home, /, немного виртуалок, одним словом дедуплицировать особо нечего):
На мои 800гб корневого пула, вообще не оптимизированного для dedup (а также 230гб бекапов с размером блока 1МБ) он дал всего лишь коэффициент 1.18, при этом на DDT потребуется 10.8М*320=3456мб ОЗУ. Оракл не рекомендует включать дедупликацию при коэффициенте меньше 2, я с ними полностью согласен.
Дедупликация — это прекрасно, но практически бесплатное lz4 сжатие (а для большинства HDD оно только ускоряет) в случае неповторяющихся данных намного целесообразнее.
Полезная ссылка.
Да, уже год активно дорабатывается и шлифуется. При чём оно разрабатывается с учётом всех недостатков реализации от Oracle, а также позволит штатными send/recieve и scrub отправлять и проверять данные на целостность без ключа.
В целом производительность будет улучшаться в следующем мажорном выпуске, но явных проблем с дедупликацией нет. Требование к ОЗУ связано напрямую с deduplication table (структура, в которой хранится соответствие контрольной суммы и блока), если DDT в неё не помещается, то будет ухудшение производительности.
Отдельно упомяну, что в бета-релизе проведена большая работа по оптимизации управления данными в ОЗУ (сокращённо ABD)
ZIL выносит журнал на отдельный носитель, а L2ARC очень похож на bcache со своими особенностями. Вот отличная статья по этому поводу.
Отдельно стоит отметить, что в случае ZFS часто хватает просто добавить ОЗУ, ARC прекрасно борется с вымыванием кеша.
На своём десктопе использую 2 WD RED в виде mirror с 16гб ОЗУ, после прогрева кеша машина работает не хуже, чем с ZFS на бюджетном SSD.
CERN и Amazon точно с вами не согласны, и это только верхушка айсберга.
У ЦЕРН в этом отчёте также есть статистика по RAID5, которая наглядно показывает, почему он ненадёжен. Приведу цитату:
Честно, я очень хотел бы с вами согласиться.
Отключение питания вообще не страшно ZFS, она атомарна, недозаписанная информация будет потеряна, но она не приведёт к какой либо ошибке в структуре.
Говоря о ZFS, стоит в первую очередь понимать, какие отличия у CoW ФС от классических. В случае ZFS даже при успешной записи новых метаданных старые метаданные не затираются в течении нескольких транзакций ZFS, что технически даёт возможность откатиться на последнее стабильное состояние (вот пример, как можно поступить при повреждении структуры).
При всём этом носитель должен быть изрядно поврежден, т.к. метаданные дублируются на разных частях.
И это естественно. Контрольная сумма (даже неверная) сработает при чтении, что спасёт от использования искажённых данных, а также спасёт от дальнейших потерь.То есть ZFS гарантирует в первую очередь проверку на корректность, такие данные в любом случае потеряны, если нет резервирования (а при использовании любого резервирования ZFS просто восстановит такой блок на проблемный носитель, хотя это является первым признаком возможного сбоя носителя в будущем).
Но этот фактор нельзя просто отбрасывать, если данные всё-таки нам дороги (всё же производители не просто так предоставляют информацию о BER). Тут скорее идёт речь о балансе надёжности к стоимости/производительности.
Только ZFS отреагирует на проблемы с оборудованием (речь про искажение информации), другие ФС будут работать уже с некорректными данными, т.к. контрольные суммы они не считают.
Можете уточнить точный сценарий, при котором ZFS сложнее восстановить?
Предполагая, что значительная часть данных с диска сохранена, и резервирование не используется — ZFS перетягивается тем же dd на другой диск, проводится штатный scrub, который выявляет все проблемы с данными, а неповреждённые блоки будут и дальше прекрасно работать (а метаданные всегда дублируются в нескольких частях диска).
Также в контексте использования на десктопах у ZFS есть возможность дублировать все блоки несколько раз (параметр copies).
Невозможность примонтирования (т.е. полный крах ФС) в счёт не беру, т.к. в этом случае проблемы будут одинаковы для всех ФС. Но и в этом случае ZFS на шаг впереди за счёт CoW (copy on write) — фактически он позволяет откатиться до последней корректной транзакции на диск.
Естественно, что рядовой пользователь не знает, как восстановить данные с любой ФС. Я не предлагаю на каждый ноутбук с Windows прямо сейчас городить ZFS (жаль, что сейчас это и невозможно), но это не значит, что самый распространённый вариант = самый верный.
Шествие ZFS в мире Unix идёт семимильными шагами, он уже используется в *BSD, Solaris, а в Linux будет штатным через 1-2 года, т.к. наконец решены вопросы с лицензией, Debian уже включил его в штатный репозиторий Stretch. Я считаю, что есть множество случаев, когда его использование оправдано.
Именно в этом случае и не соглашусь, ZFS создавалась с упором на ненадёжность носителей, что прямо относится к недорогим HDD, взять хотя бы подсчёт контрольных сумм всех данных. В отличии от него, другие ФС отдадут то, что выдал HDD, без проверки.
И уж если мы заговорили о надёжности железа, то оно от ФС не зависит.
Извиняюсь, что не уточнил — в Linux, для Windows вариантов особо и нет :) Для Linux понятия родной ФС в вашем случае можно заменить на наиболее используемую, видимо это ext4.
Также интересно узнать, есть ли у вас какое-то мнение по поводу надёжности файловых систем, что лучше или хуже?
Извиняюсь за излишнюю эмоциональность, но это не отменяет явных недостатков raid5 на дисках большого объёма хотя бы из-за BER. Да, он работает, но при сбое вероятность потерь меня очень смущает.
Я не утверждал, что она не падает, к сожалению всё может в какой-то момент дать сбой. Наоборот, как раз сторонники ZFS наиболее яро пропагандируют эту идею, в частности только они явно выделяют рекомендации по ECC памяти.
Не хочу спорить, лично для меня это вопрос из разряда «мыши плакали, кололись, но продолжали есть кактус». Я понимаю, что у каждой ФС свои плюсы.
Кстати, у вас уже был опыт восстановления ZFS?
Также очень интересно было бы узнать ваши предпочтения по ФС.
Всё верно, в таком случае используется snapshot, он позволяет создавать инкрементальные срезы хоть каждую минуту. Но сразу оговорюсь, что не стоит подменять им полноценный бекап на другую машину (а в таком случае снапшоты также прекрасно передаются по сети в инкрементальном режиме).
Вообще, после zfs я уже не представляю, как можно жить без снапшотов и хеширования данных. На моей машине настроено создание снапшота всей системы раз в 15 минут, и это никак не влияет ни на производительность, ни на простои (см. https://github.com/zfsonlinux/zfs-auto-snapshot )
Спасибо всем за поддержку, статье быть, и не одной:)
Если интересно, готов рассказать про многие вопросы ZFS, т.к. являюсь контрибьютором. В планах статья-howto с описанием дел на настоящий момент.