Comments 69
Когда появилась ZFS, это была революционная система
Но ZFS по-прежнему намного превосходит старые файловые системы для домашнего пользователя.
На этот счет все было сказано еще в 1912 году — "Узок круг этих революционеров. Страшно далеки они от народа."
Но дело их не пропало. Декабристы разбудили Герцена. Герцен начал революционную агитацию
ZFS отличная система для хранения важных, нечастно изменяемых данных. Профиль нагрузки: записал один раз, читай всегда. Файловая система для ОС, ПО, backup-ы, файлопомойки.
Из-за отсутствия проверки целостности, избыточности и восстановления после ошибок ext3/4 (Linux) абсолютно не подходят
В ext4 есть контрольные суммы для метаданных, и она же журналируемая поэтому конечно есть восстановление после ошибок.
контрольных сумм для просто данных — нет ни там, ни там.
В mdadm точно так же — нет.
Linux software RAID is not going to protect you from bit corruption and silent data corruption is a well known issue with it. In fact, if the kernel is able to read the data from one disk it would never know that it is bad. The RAID only kicks in if there is an I/O error when reading the data.
У меня на работе среди прочего есть NAS Thecus, в последней прошивке появилась ZFS и, поддаваясь на сладкие речи коллеги Linux-гуру, решил поставить ее. А памяти то там был 1 гиг, кто ж знал… Таких тормозов, а часто и вислова, я не видал давно… Добавления памяти до 4 гиг не помогло. Мало того, что все тормозило, так и некоторые файлы и папки заблокировались, так что копирование с него данных для последующего снесения нафиг и переформатирования под ext4 привело к некоторой потере. Благо это была файлопомойка и хранилище некритичных и дублируемых в другом месте бэкапов, так что не очень расстроился. Теперь вот стоит ext4 и 2 гига памяти. Все летает, тьфу тьфу тьфу
NAS4FREE на плате Intel D525MW, Atom525, 2*1G памяти, два диска 5400 оборотов, зеркало на zfs.
Сценарий использования — бэкапы, файлопомойка, торренты скрещенные с miniDLNA сервером для телека.
Никаких зависонов и вообще проблем, аптайм месяцами.
Были глюки и отвалы при просмотре тяжелых фильмов, долго искал причины и ругался на zfs, оказалось тупо битая память
8Gb сегодня стоят недорого, особенно если вспомнить цену нескольких дисков в тот NAS и самого NAS.
Я на опыты создал на на стареньком 2-х ядерном ксеоне рейд zfs с дедупликацией (около 400гиг доступно) и 8 гигабайт памяти. Памяти мало. при некоторых операциях записи я получаю скорость работы около 1,5мб/с. Скорость чтения при таких ситуациях всего несколько десятков кб/с. Процессор не нагружен. Эта файловая система как по мне может работать адекватно только на бекапы. Но стоит её расшевелить изменениями данных и минимальная скорость гарантирована.
Для файлового хранилища более чем система. Для нагруженного хранилища zfs не годится. Сколько этой штуке понадобится памяти при 12 терабайтах и дедупликации? При любых настройках, включая работу без сжатия и дедупликации я не смог выжать скорости записи более 70мб и 60мб на чтение.
Сами накопители в конфигурации рейда (аналог рейд 10) способны выдать около 170мб/с.
«При любых настройках, включая работу без сжатия и дедупликации я не смог выжать скорости записи более 70мб и 60мб на чтение.»
когда это было, с каким софтом, в каких условиях?
Подключение через iSCSI, гигабитная сеть. Скорость чтения/записи больше всего по графику напоминают зубья пилы. Скорость небольшая (40мб/с), потом идет рост вверх, доходит пика (80-90мб/с) и опять падает до 40. Какое-то время держится и опять все с начала. Синхронная запись/чтение вообще заваливает чтение до нескольких мб/с в хороших условиях, в плохих там кб/с. В начале думал свич, но такое поведение получилось только под управлением NAS4Fre. К содалению не проверял на других файловых системах. Сама система старые серверок с 6-ю дисками.
Эти вещи очень любят жрать ресурсы.
" Синхронная запись/чтение " это отдельная тема.
В общем, Ваши тесты — подтверждение тезиса, что включая «все фичи по максимуму», можно положить всё.
Сейчас работает с дедупликацией. Объема памяти если верить тому, что есть в инете более чем достаточно. На практике маловато, но это машина для бекапа с ограниченным объемом, ночью времени хватает. Но скорость как писал при записи может достигать около 10мб/с или меньше, а синхронное чтение десятки кб/с.
Но и без дедупликации скорость не конек данной системы. К сравнению виндовс сервер с не страдает проблемой скорости. Может там фич меньше просто :)
Там тупо нет многих фич или же они сделаны примитивно.
Например, бэкап всего раздела на «живой», работающей NTFS — это практически полное замирание работы разделов, которые бэкапятся.
Сравните с Zfs snapshot.
«Сейчас работает с дедупликацией.… синхронное чтение десятки кб/с.»
Подозреваю, таки мало памяти.
Zfs snapshot все же фича, а не просто копирование.
Я тоже думаю, что все упирается в память, но было написано мол 8 гигабайт хватает для 1 терабайта на носителе. По факту это оказалось не так. Файловый сервер скажем на zfs я бы не собирал. Может если будет когда возможность погонять машину с большим кол-ос памяти и посмотрю, но в стесненных условиях такая файловая система работает не лучшим образом.
Рекомендую прочитать этот комментарий, давал в нём методы точного расчёта требований.
Также добавлю, что ОЗУ требуется для записи, на чтение дедупликация не влияет (только если вы записываете параллельно с чтением, и при этом у вас кончилась ОЗУ, тогда для каждой операции записи будет много случайных IO чтения на диск).
72Gb RAM.
При активной записи в хранилище можно заметить, как память забивается буквально на глазах. Кеш ZFS будет отъедать всю свободную память — к гадалке не ходи.
Самой дорогой частью будут винты
12 штук пошли в работу, 8 лежат как запасные. Вся железяка без винтов обошлась чуть больше 1.5К, вместе.
На мой взгляд — достаточно недорого, свои данные я ценю гораздо выше.
А интеграция этой ФС с Linux через такую-то матерь только добавляет эпичности сюжету.
Насколько я понимаю, ZFS on Linux — такой же модуль ядра, как ext4 и другие.
Во FreeBSD zfs.ko тянет за собой в зависимостях opensolaris.ko. Для чего? Не для того же?
Но если посмотреть на СХД типа VNX или Celerra, то обнаруживается, что ZFS может больше, хотя та же Celerra стоила в 2010-м около четырех миллионов рублей. В тех задачах, в которых я использовал VNX и Celerra, мне не хватало на ZFS разве только что автотиринга, да Fibre Channel, хотя последнее решаемо, в принципе.
А в случае варианта с «бюджетной СХД» (компьютер в 3U корпусе и с ECC памятью), которая отдает LUN по iSCSI в ESXi, да файлы по SMB — ZFS это «то, что доктор прописал»
P.S. Сугубо личное мнение
которая может даже использовать SSD и 3D-XPoint как уровень или кэш.
Не совсем понятно, что имеется в виду под «уровнем». В оригинале «tier». Подозреваю (хотя и могу ошибаться), что имеется в виду «которая может даже использовать SSD и 3D-XPoint либо для хранения данных, либо в качестве кэша».
В первый раз я потратил много времени на очистку. Пришлось внешний хард форматировать в btrfs, добавлять в разделу и запускать команду balance. А после удалять его из набора, чтобы данные опять перекочевали обратно.
Возможно на серверах файловая система btrfs хороша, но на рабочих лошадках пока рановато ставить. Или постоянно проверять «реальное» свободное место командой «btrfs fi sh» В ближайшее время опять вернусь на ext4
Четыре года назад поставил btrfs на домашний сервер, правда тогда убунта еще на корень ее ставить не умела без бубна, так и работает — корень на reiser, а /data на btrfs
А два года назад на домашний, уже на корень.
На ноуте с покупки была ext4 так что не трогал.
Вроде с местом все ок показывает, и когда сервер забился на 100% проблем не было, просто потер и все ок.
После удаления диска из raid 1 и добавления нового в процессе апгрейда — система перестала монтироваться. Попытки заставить её монтироваться всеми способами из мануалов, включая различные методы восстановления привели к потере части файлов. Смог спасти остальное только благодаря тому, что удалённый диск смонтировался в degraded состоянии.
С тех пор — больше не связываюсь с ней, перешёл на zfs. С контейнерами она, кстати, отлично дружит в связке с proxmox ve.
RAID выше первого я не пробовал (боюсь). RAID1 работает несколько лет на нескольких серверах без каких-либо проблем на Ubuntu 14.04 (ядра 3.13, 3.19 и 4.4 от Убунту) и Oracle Linux UEK3/4 (ядра 3.8 и 4.1 с многочисленными Оракловскими патчами и бэкпортами). Попытка сделать то же самое на ядре 3.10 в Centos 7 привела к довольно скорому развалу массива. Кое-как удалось собрать его и срочно мигрировать на mdraid + ext4. В Центосовском ядре btrfs, насколько я понимаю, какой-то недоделанный.
Для Windows компания Microsoft тоже собирается выкатить собственную файловую систему нового поколения ReFS с использованием деревьев B+ (похоже на Btrfs), с сумасшедшим масштабированием и функциями стойкости и защиты данных
ReFS уже давно есть в серверных редакциях ПО(по-моему с вин сервер 2012), уже есть и в вин10, не уверен правда мб пока только в инсайдерских сборках.
Там нет защиты данных от повреждения, точно также, как в большинстве файловых систем по умолчанию.
Для обычного домашнего компьютера это ОК.
Да и вообще, почему этим должна заниматься файловая система?
P.S.: И таки она вышла только для iOS, для MacOS выйдет чуть позже, пока в бетах.
2 Особенности
2.1 Снимки файловой системы
2.2 Шифрование
2.3 Целостность данных
2.4 Защита от сбоев
APFS не поддерживает контрольных сумм для данных, я слишком общо выразился.
Есть прекрасный обзор APFS с точки зрения разработчика ZFS.
Мне кажется, что с приходом SSD, актуальность WAFL-подобных файловых систем теряется: нет особой нужды гнаться за оптимизацией скорости случайной записи (ухудшая скорость линейного чтения за счёт фрагментации), когда можно использовать SSD для тиринга и кэша записи. Опять же, внутри всех без исключения SSD всё равно свой WAFL и прямого доступа к ячейкам/строкам SSD не предоставляет.
Подобная ситуация уже была в индустрии, когда выдающаяся по своим характеристикам HPFS от IBM на основе нормализованных двоичных деревьев с распределённым хранением метаданных канула в лету, как только оперативной памяти стало достаточно, чтобы закэшировать все «примитивные» табличные структуры FAT/NTFS.
Кроме оптимизации случайной записи, плюсами WAFL/ONTAP, и последующих клонов (в т.ч. ZFS) были:
- Сквозные контрольные суммы — в том или ином виде это будет внедрено со временем везде, о чём автор и упоминает. Прямой связи с WAFL-подобными системами у этой технологии нет — в оригинале NetApp заказывала SAS-диски с нестандартным размером сектора, на массовом рынке это невозможно, так что приходится выкручиваться, кто как может, в том числе и в не-WAFL-подобных системах.
- RAID-DP благополучно превратился в вариации на тему RAID-6 (RAID-Z2 etc) и стал уже стандартом de facto. Опять же, WAFL-подобное размещение для этого не обязательно.
- Снэпшоты реализованы на уровне систем виртуализации, а поскольку почти все нагрузки на сегодняшний день виртуализованы, реализация этого механизма на уровне дисковой подсистемы не так привлекательна, как раньше.
Как видно, основные «killer features» либо потеряли свою актуальность, либо реализуются вне зависимости от типа размещения данных. Но, безусловно, инженерам-первооткрывателям стоит сказать «Спасибо!», вот только большинство открытий было сделано в стенах NetApp, а не Sun.
[Disclaimer: за 100% историческую достоверность фактов не ручаюсь, писал по памяти. Если что неверно в описании, кто чей клон — пожалуйста представьте свою версию в комментариях, помню в своё время было много споров на этот счёт.].
Так что скажем спасибо IBM за многомилионные мейнфреймы, благодаря которым у каждого есть дешевые компьютеры, скажем спасибо NetApp, что их разработки, окупившись в энтерпрайзе, пошли «в народ», и скажем «спасибо» Ораклу, похоронившему дальнейшую разработку ZFS, благодаря чему мы застряли в прошлом десятилетии с файловыми системами.
P.S.: Снапшоты при помощи систем виртуализации для файлового хранилища — это как-то странно. У решений поверх стандартных файловых систем они дадут значительно больший оверхед, у VMWare они интегрированы с файловой системой (=тот же подход, что у wafl/zfs)
Но, для своего времени — да, это тоже были потрясающие инновации.
Как показывают сотни рабочих ПК регистровая память все же не настолько критична. У кучи контор сервера на обычном ПК и работают пока не разрушаются диски.
При этом я не агитирую за отказ от ECC — себестоимость девятого чипа памяти уже давно минимально влияет на цену серверной RAM. Есть — и ладно, всем спокойней, этакое плацебо.
Суть end-to-end checksum в ONTAP, ZFS и т.д. как раз в том, чтобы отследить ошибки на любом этапе, ведь кроме основного ОЗУ те же биты проходят через множество других подсистем, в которых информация тоже может повредиться.
Что касается именно связки ECC+ZFS, вот довольно интересная, на мой взгляд, статья: Will ZFS and non-ECC RAM kill your data?
В свете отказа RedHat от поддержки btrfs начиная с rhel 7, в Linux альтернатив zfs не остаётся.
Позиция автора: используйте ZFS (пока)
В статье много сравнений ZFS с другими ФС, но выбранные ФС, увы, почти все на тех ОС, где ZFS никак не получится использовать. Поэтому сравнение напоминает классику «ноги — крылья — хвосты», но не дает выбора.
Вместо NTFS уже давно было бы очень неплохо взять что-то поинтереснее. ZFS был бы просто идеальным вариантом (плюс, из-за массовости платформы, появилась бы тысяча утилит по более-менее обслуживанию ZFS). Но говорить, что NTFS устарела, а ZFS держится (пока), так что ее и надо использовать — это как-то нечестно.
Вот и вопрос, что советует автор: выбирать ОС, где работает ZFS, или как?
TFS (про которую уже выше написали) сейчас выглядит очень многообещающей. Ей бы прорваться в разные ОС — был бы просто праздник, но это такая огромная работа, что говорить о реальности сложно.
Concurrent
TFS contains very few locks and aims to be as suitable for multithreaded systems as possible. It makes use of multiple truly concurrent structures to manage the data, and scales linearly by the number of cores. This is perhaps the most important feature of TFS.
Asynchronous
TFS is asynchronous: operations can happen independently; writes and reads from the disk need not block.
Full-disk compression
TFS is the first file system to incorporate complete full-disk compression through a scheme we call RACC (random-access cluster compression). This means that every cluster is compressed only affecting performance slightly. It is estimated that you get 60-120% more usable space.
Revision history
TFS stores a revision history of every file without imposing extra overhead. This means that you can revert any file into an earlier version, backing up the system automatically and without imposed overhead from copying.
Data integrity
TFS, like ZFS, stores full checksums of the file (not just metadata), and on top of that, it is done in the parent block. That means that almost all data corruption will be detected upon read.
Copy-on-write semantics
Similarly to Btrfs and ZFS, TFS uses CoW semantics, meaning that no cluster is ever overwritten directly, but instead it is copied and written to a new cluster.
O(1) recursive copies
Like some other file systems, TFS can do recursive copies in constant time, but there is an unique addition: TFS doesn't copy even after it is mutated. How? It maintains segments of the file individually, such that only the updated segment needs copying.
Guaranteed atomicity
The system will never enter an inconsistent state (unless there is hardware failure), meaning that unexpected power-off won't ever damage the system.
Improved caching
TFS puts a lot of effort into caching the disk to speed up disk accesses. It uses machine learning to learn patterns and predict future uses to reduce the number of cache misses. TFS also compresses the in-memory cache, reducing the amount of memory needed.
Better file monitoring
CoW is very suitable for high-performance, scalable file monitoring, but unfortunately only few file systems incorporate that. TFS is one of those.
All memory safe
TFS uses only components written in Rust. As such, memory unsafety is only possible in code marked unsafe, which is checked extra carefully.
Full coverage testing
TFS aims to be full coverage with respect to testing. This gives relatively strong guarantees on correctness by instantly revealing large classes of bugs.
SSD friendly
TFS tries to avoid the write limitation in SSD by repositioning dead sectors.
Improved garbage collection
TFS uses Bloom filters for space-efficient and fast garbage collection. TFS allows the FS garbage collector to run in the background without blocking the rest of the file system.
А что именно такого интересного заявлено среди целей TFS, чего не заявлено для ZFS/Brtfs?
о Brtfs по ходу уже можно начать забывать. Признав ее deprecated RHEL как бы дает нам намек.
ZFS — лучшая файловая система (пока)