Комментарии 48
И ни слова о том, что ZFS это COW система. Самое главное забыли. =)
Написано, просто не названо CoW (если не считать подписи под картинкой):
Это работает благодаря методу записи ZFS: при изменении блока обновленные данные записываются в новое место, а старый блок помечается как свободный.
пупупу. возможно и правда стоило указать это явно. мне этот момент казался "настолько очевидным, что нет смысла описывать", цитируя великих
UPD: к тому же это уже было сказано в предыдущей публикации)
А если строго, то zfs использует redirect on write, что намного быстрее чем классический copy on write как в обычном не тонком томе lvm, когда каждый новый снимок драматически понижает быстродействие записи.
Для zfs есть очень подробная дока от oracle на русском языке, которую я читал как интересный роман!
BTRFS тоже.
Мдя.
FreeBSD handbook - The Z File System (ZFS)
ZFS is an advanced file system designed to solve major problems found in previous storage subsystem software.
Originally developed at Sun™, ongoing open source ZFS development has moved to the OpenZFS Project.
OpenZFS on Linux and FreeBSD - Releases zfs-2.3.3 last week
OpenZFS documentation
Performance and Tuning
Давно использую:
ZFS on Linux - Proxmox VE
Разве?
Это работает благодаря методу записи ZFS: при изменении блока обновленные данные записываются в новое место, а старый блок помечается как свободный.
inkvizitor68sl, [07.07.2022 23:30]
у меня недавно 2 хоста с zfs ушли в вечный d-statenikoinlove 🐈, [07.07.2022 23:36]
[In reply to inkvizitor68sl]
вот такой зфс я узнаюnikoinlove 🐈, [07.07.2022 23:37]
а работает с 2 гигами рам на рейдз не очень узнаю
Думаете, за 3 года что-то сильно поменялось? -)
(ЗЫ - 2 из пяти)
Вы упустили важный момент в своём рассказе о zfs на linux. То что использование ARC кеша в linux происходит без отключения стандартного механизма кеширования linux. Таким образом одни и те же данные могут лежать в кеше linux и в ARC (а потом еще L2ARC). Так же это генерирует бестолковые копирования между этими слоями абстракций повышая нагрузку и латенси.
Увы и ах, zfs для linux это сторонний продукт под несовместимой лицензией. Надежд что в последнем организуют механизмы позволяющие уйти от двойного кеширования - их буквально нет. Для этого, насколько я понимаю, нужно "всего лишь" переписать VFS. И этим точно никто и никогда не займется для какого-то левого проекта сбоку.
Так что для zfs, как это не парадоксально для 2025, нужно использовать FreeBSD (хоть какая-то область крепко держится за этой старушкой). Особенно если предполагается использование исключительно как NAS или SAN.
Ещё большей чепухи я в жизни не слышал
Есть по существу сказать что не так и как на самом деле?
Двойного кеширования (ARC + page cache) zfs в linux нет?
OpenZFS (каноническая реализация zfs) лицензированна под gpl и вот вот войдет в ядро Linux?
zfs работает во FreeBSD хуже чем в Linux?
по существу:
1. двойного кэширования нет (за исключением mmap()), т.к. в слое vfs со стороны zfs оно намеренно не реализовано, соусы:
реализация слоя vfs - https://deepwiki.com/openzfs/zfs/3.1-vfs-layer-and-posix-interface
годная лекция о том, как в zfs устроены чтение и запись - https://openzfs.org/wiki/Documentation/Read_Write_Lecture
и вот тут прямым текстом сказано, что arc заменяет дефолтный page cache с его lru - https://openzfs.org/wiki/System_Administration
2. openzfs использует лицензию cddl, в ядро линукса по этой причине не войдет, но это не мешает ее использовать. может apt install zfs-initramfs или даже сборка модуля ядра ручками все же стоит получения гибкого и эффективного инструмента хранения?
3. очень странный тейк. обычно ос выбирается исходя из задач, которые собираешься решать на машине, а не какую фс хочешь использовать. но для меня zfs всегда был просто крутым инструментом и я не вижу ничего плохого в том, чтобы подружить его с любимой ос
для меня zfs всегда был просто крутым инструментом и я не вижу ничего плохого в том, чтобы подружить его с любимой ос
Даже с Windows? :-)
а windows у меня далеко не любимая ос)
ну и в теории через wsl сделать это можно...
The Windows port is still in Beta, it's true,
Though your ZFS data should safely pull through.
But crashes might happen, bugs may arise,
From upstream or here—there could be surprise.
https://github.com/openzfsonwindows/openzfs/blob/development/README.md
так-то статус продукта - крайне эфемерная вещь. гмейл был в статусе беты (со всеми соответствующими предупреждениями от гугла) в то время, когда им уже пол-мира пользовалось
у игроделов же, например, принята другая стратегия и там продукт релизится, а юзабельным становится только после пучка патчей...
Реально нужен не статус, а чтобы данные оставались в сохранности.
безусловно, но разве, скажем, ZFS для линукса где-то дает такие гарантии?
Да, можно предположить, что, раз количество инсталляций кратно выше, то продукт должен быть более вылизанным, но это же субъективный показатель
P.S. И нет, я не призываю всех скопом идти ставить ZFS на винду, я лишь отмечаю, что статус продукта - отражение мировоззрения его разработчиков. Иные бета-продукты куда стабильнее тех, которые релизятся
Нет никакого двойного кеширования там, откуда вы берёте этот бред?
Еще неплохо используется SPECIAL VDEV для хранения метаданных на отдельных ssd.
Из моего опыта, special vdev вдвое понижает iops на основные vdev при той де нагрузке на пул. Разумеется, он ещё ускоряет все операции с метаданными.
окак. так и не удалось на живом примере опробовать их. звучит слишком хорошо, чтобы быть правдой, поэтому видимо в список покупок добавляются два оптана)
Ускорение будет только если все метаданные уже на optane, пул нужно пересобрать с нуля. Но для special vdev как мне кажется, можно взять что-то попроще, типа intel s3610 / intel p4610, тем более, что метаданных на больших пулах может скопиться довольно много.
Зато optane идеальный вариант для dedup vdev, вернее с другими ssd/nvme даже можно и не пробовать: будет по началу нормально, но потом, когда таблица дедупликации станет побольше, все станет очень грустно. Один vdev на optane (с резервированием) позволит записывать со скоростью примерно 500 мегабит/c сжатого трафика. Это очень примерно. Сжатого, я имею в виду, что после сжатия останется 500 мегабит, т.к. при записи вы скорее всего сожмете данные, это позволяет исключить неопределенность связанную с коэффициентом сжатия данных. Сжатие позволит к 30-200% утаптывания zstd сжать ещё в 2-3 раза за счет дедупликации на блочном уровне. Но имейте в виду, дедуплицированные данные продолжают занимать место своими метаданными на special vdev, может оказаться, что 800GB для special будет мало.
Ещё можно на optane разместить slog, чтобы перенаправить синхронную запись на него, что даст выигрыш для баз данных.
Не стоит игнорировать cache vdev на чем-то типа intel P4510 - он должен быть большой, но не требуется избыточность и адская устойчивость к записи, zfs с cache vdev обращается бережно - это снимет ещё больше iops с основных vdev.
Но тут хотелось бы сразу предупредить. zfs - это не про попугаи в тестах. За частую можно наблюдать такую ситуацию: если тупо взять диски и объединить их в raid0 и lvm-ом нарезать, то на полученных устрйоствах попугаем может быть внезапно больше чем на zfs (там ведь транзакционная запись, чексуммы, сжатие). Но если вы нагрузите zfs и raw raid0, то увидите, что zfs потянет в разы, часто в 10-ки раз, а иногда и в стони раз большую нагрузку, чем та, на которой заткнётся raw raid0.
zfs скорее похож на карьерный самосвал, чем на гоночный балид.
Хочу заметить что это справедливо только для raidz инсталляций, но тут в любом случае надо отталкиваться от количества iops special диска, есть формула по которой считаются iops raidz, для рейда с двумя паритетами iops будут меньше в два раза чем у одного диска, поэтому отдельный диск с большими iops под zil или l2arc может быть очень полезен. Но если собирать zfs miroring (raid10), iops наоборот будут в два раза больше и тут диск под l2arc или zil будет наоборот мешать. Конечно нагрузка так же играет большое значение, например все синхронные записи такие как записи баз данных или виртуальных машин использует zil, если таких нагрузок нет, то и особого смысла в ZIL на отдельном диске не будет, а l2arc используется для любых видов чтений, поэтому если спешл диск медленный, разворачивать l2arc на нем может оказаться невыгодным.
В последующем в первую очередь расскажите о pool checkponit , все остальное - потом. А то я как то раз добавил в raidz "не тот" диск , и .... всё.
Собирали франкенштйена из mdadm, LVM и bcache?..
Между прочим, обращаясь к первоисточникам («Франкенштейн, или Современный Прометей» М. Шейли), Франкенштейна никто не собирал. Он сам кого хочешь соберёт: «В книге рассказывается о жизни и трудах учёного Виктора Франкенштейна, которому удалось постичь тайну зарождения жизни и научиться оживлять безжизненную материю. Франкенштейн создает искусственного человека из частей трупов, но позже отрекается от своего детища.» Впрочем, сам недавно об этом узнал.
Спасибо, читать материал очень приятно!
По теме zfs очень требовательна к железу. До неё в проде всю дорогу использовали накопители не серверного сегмента в рейде 10, т.к. пользователей мало, нагрузка щадящая. После перевода па проксмокс с zfs samsung 870 EVO на 4 ТБ сдались через полтора года почти одновременно на всех серверах. Pveperf меньше 50. Причём по смарту диски как новые, скорость записи/чтения ровненькая при тестировании на весь объём, но даже под систему на пк использовать теперь невозможно.
Этот случай самый яркий, но даже при нагрузке в 50 пользователей резервного DC, сервера печати, парой тестовых виртуалок, с кучей свободного места (чтобы, случись чего, из бэкапа файловый сервер на время восстановить) крушиалы и самсунги долго не живут почему-то.
Обычные пользовательские SSD обычно имеют SLC кэш 10-20% от обоего объема. Пока запись идёт в него - диск показывает хорошие показатели производительности. Как только SLC кэш заканчивается и начинается TLC или ещё хуже QLC - иопсы просто испаряются. Если запись в диск происходит регулярно, то SLC кэш просто забивается. Серверные ссдшки же демонстрируют на всем объеме одинаковые показатели производительности
Немного в курсе про суть работы TLC технологии :) . Дело в том, что диски умирают совсем, даже после форматирования использовать не получается.
После прочтения статьи у читателя может возникнуть мысль о том, что zfs решает все проблемы, даже о которых он никогда не слышал. Нужно просто добавить три ссд диска для кэширования. На практике же не зря эта файловая система, при всех своих колоссальных возможностях за пределы энтерпрайза не выходит, накладные расходы там очень приличные. Качественное серверное железо это только одно из.
Не пытаюсь в чём-то переспорить или упрекнуть автора или выступить против файловой системы. Просто хотел предостеречь читателя. С интересом буду наблюдать за дальнейшими статьями. Написано, повторюсь, очень приятно.
Окак. А смарт что говорит? Сколько было записано в диски? Просто даже интелевые серверные диски (nand, не оптаны) у меня показывали признаки деградации после 700 впитанных тб. Кроме того для некоторых юзкейсов использование sata ssd для l2arc противопоказано: в последовательном чтении у 1ого sata ssd вполне вероятно выиграет radizX с несколькими hdd. Себе для l2arc я выбрал NVMe оемник - Hynix pc801 (он же Hynix P41 Platinum, он же Solidigm P44 Pro). Такое решение быстрее raidzX на жестких дисках как по пропускной способности, так и по IOPS-икам. Глянул смарт: за 2к часов впитал в себя всего 1.8тб, видимо проживет еще долго)
А вы как те диски форматировали? Встроенным в ФС инструментарием? Вот мне интересно тут, если для удаленных файлов TRIM/discard делать научились, то "форматирование" (как мне думается Windows) это тоже умеет делать или нули пишет? Нули-то дедуплицироваться прошивкой могут. У меня на Phison контроллере так и было.
NVMe SSD сбрасывал через nvme-cli. У SATA помимо Secure Erase тоже свои команды должны быть. На крайний же случай на всё блочное пространство вручную TRIM/discard разослать.
И стандартное: после этого пару (десятков) гигов в конце пустыми оставить и не трогать. Хотя, технологически, это уже устаревший совет должен быть, коли discard нормально отрабатывает.
В zfs надо включать diskard или выполнять его вручную, чтобы он не снижал быстродействие во время интенсивной записи с высвобождением блоков:
# Выполняем diskard вручную
zpool trim poolname
# Включаем автоматический diskard
zpool set autotrim=on poolnameХороший совет, надеюсь автор добавит в следующие статьи. Когда разбирался сам нашёл эту фичу далеко не на первой странице. Странно, почему она выключена из коробки...
Серверным накопителям не горячо не холодно от неё, т.к. внутри запас скрытого объема 30-40% и мощный контроллер с объемной ОЗУ и конденсаторами для гарантированной записи находящихся в буферах данных. Буферизация и остальные особенности серверных накопителей сильно снижает умножение записи вызванное неудобной последовательностью записи мелких блоков.
У бытовых SSD нет таких роскошных возможностей: места впритык, свободных блоков достаточно только пока SSD не заполнен, контроллер слабый, и унего мало или вообще почти нет ОЗУ, а даже если ОЗУ есть, в нем нельзя буфферизировать записываемые данные ,т.к. нет конденсаторов, что вкупе, не позволяет использовать продвинутые алгоритмы уменьшающие износа ячеек.
Не используйте бытовые SSD на серверных нагрузках ни с ZFS ни с другими системами хранения.
Уже добавлено недельку назад) Скоро публикация
Да что только не делал, и пулы пересобирал и оставлял неразмеченными 3 ТБ из 4 и в винде с NTFS пытался использовать, жалко же выбрасывать. И постоять сутки давал, чтобы контроллер со своим TLC разобрался)
Понял. Значит всё равно советую попробывать сбросить весь namespace через nvme-cli (предпочтительней) или TRIM: https://superuser.com/questions/308251/how-to-trim-discard-a-whole-ssd-partition-on-linux . Если есть возможность.
Не думаю, что это связано с zfs, скорее, эти nvme рассчитаны что на них будет работать одна машина, а весь оставшийся объем будет простаивать. А в гипервизоре, нагрузка была кратно большей расчетной. по моему, лучше в такой ситуации купить бу intel P4610, intel S3700 (для баз данных), optane (для нагруженных баз данных). Другими словами, дело не в zfs, а в том что nvme впринципе не расчитаны на такой сценарий.
Однако, совершенно точно, zfs увеличила количество iops примерно вдвоё, ведь она не только записывает данных, но и закрывает ранзакции - это примерно вдвое ускоряет износ. Для серверных nvme - этот фактор не существенен. У меня есть nvme более 5 лет работающие (intel P4610 / intel s3700/ intel optane), причем под завязку забиты работающими виртуальными машинами. На optane вообще базы данных один.
Ещё момент, коньсюмерские nvme могут иметь технологию выравнивания износа, которая намеренно снижает быстродействие не позволяя изнасиловать диск так, что он бы вышел из строя до окончания гарантии. Выглядит этот как постепенное снижение скорости записи. Дайте им постоять недельку во включенном виде и скорость восстановится (а ещё можно их очистить через security erase, тоже начнут быстро работать).
А ещё nvme бытового класса могут всегда показывать 100% здоровья, просто у них отключен этот индикатор, чтобы не нервировать пользователей - здорово они придумали, да?
франкенштйена
Кого??? :)
Мало того, что опечатка, но ещё и некорректное употребление термина. Давайте не будем путать учёного по фамилии Франкенштейн и чудовище Франкенштейна.
Всё правильно, разве что вот dmcryptубирать из стека не стоит. С производительностью у нативного шифрования всё плохо: https://github.com/openzfs/zfs/issues/13736
По моим тестам падение скорости (по сравнению с dmcrypt) почти в 4 раза.
Так что я вернутся а zfs-over-dmcrypt - да, это геморройнее, нужно каждый диск сначала дешифровать, но небольшой скрипт помогает.
Оно было плохо, в ZFS 2.2 шифрование очень серьезно подтянули.
Ну, наверное оно было ещё хуже.
Я тестировал как раз 2.2 и потом 2.3, шифрование в разы медленнее чем dm-crypt. Ну и баг по ссылке выше до сих пор открыт и никто особо не чешется его править. Создатель того issue накидал скрипт для тестирования через TMPFS, легко проверить.
У меня 10Гбит сеть, поэтому мне этот вопрос актуален, со встроенным шифрованием я упираюсь в него, а не в сеть или диски.
Собирали франкенштейна из mdadm, LVM и bcache? Теперь попробуйте ZFS