Комментарии 30
Linux-компьюнити совершенно право, что не интересуется проблемами разработчиков модулей с несовместимыми лицензиями.
Сделайте совместимую лицензию да вливайтесь в апстрим, будет вам всё богатство ядра.
Linux-компьюнити совершенно право, что не интересуется проблемами разработчиков модулей с несовместимыми лицензиями.
Я уточню — оно (якобы) не интересуется ВООБЩЕ всеми сторонними модулями, не зависимо от их лицензий.
Сделайте совместимую лицензию да вливайтесь в апстрим, будет вам всё богатство ядра.
Скажите это Ораклу :) Всё, что не связано со старым кодом времён Sun — уже GPL-совместимо. Да и в апстрим вливаться — не самоцель. Просто зачем специально портить жизнь другой части opensource коммьюнити такими шагами?
Конечно же, самая ожидаемая — нативное шифрование.Уже существующий пул зашифровать можно?
мейнтейнеры ядра проявляют явную незаинтересованность в помощи сторонним модулям
Это ещё мягко сказано. Вот такое вот — это просто мелкое вредительство.
> -EXPORT_SYMBOL_GPL(kernel_fpu_begin);
> +EXPORT_SYMBOL(kernel_fpu_begin);
...
> -EXPORT_SYMBOL_GPL(kernel_fpu_end);
> +EXPORT_SYMBOL(kernel_fpu_end);Ладно бы, если бы эти функции содержали какое-то know how или реализацию чего-то хоть немного сложного, а не банальное сохранение состояния FPU в согласованном для ядра состоянии. А так это огораживание и просто мелкая палка в колеса.
Они б ещё запретили стороннему коду работать на более чем одном ядре CPU для полного "счастья".
При этом одним из аргументов было "мы не хотим себе дополнительных трудозатрат для не GPL кода". Ага, вот эти 8 символов "лишних" — огромные затраты :)
Если прочитать хвалебные статьи и броситься с головой в ZFS, кажется что всё круто и лучше системы нет.
Я сначала тоже так думал после анализа материалов, в которых описываются плюсы ZFS, но когда стал разбираться подробнее, оказалось что всё не так радужно, как кажется.
Самое больное — это если нужно расширить хранилище (с 2 до 3, с 3 до 4 дисков и т.п.), то это выходит дорого и неудобно, потому что в отличие от mdadm в RAIDZ нельзя добавить новое устройство — надо куда-то слить данные, которые лежат и заново создавать пул. Ещё есть тревожные звоночки от людей, которые заменяли диски в пуле, у которых число секторов было меньше, чем в исходных.
Судя по тестам (правда, чужие бенчмарки — это бабка надвое сказала), COW довольно сильно просаживает скорость чтения/записи.
На самом деле (тут конечно наверняка палками побьют любители ZFS), почти всё можно реализовать средствами линуксовых dm/md — это lvm, mdadm, luks, vdo и т.п… Это конечно приведёт к работе на много часов, т.к. утилиты ZFS намного лаконичнее и из-за того, что заточены только для ZFS — проще (LVM при этом может жонглировать чем угодно, что похоже на блочное устройство), но после первого раза будет не так жутко.
Плюс, безусловно, у ZFS есть довольно неплохие киллерфичи вроде zfs send, снепшоты полегче чем в LVM, сжатие вообще нормально работает.
Но NAS и другие такие коробочки один раз настроил и забыл, и если что-то сломается, по традиционным для Linux инструментам найти что-то в сети скорее всего будет намного проще.
Я сначала тоже так думал после анализа материалов, в которых описываются плюсы ZFS, но когда стал разбираться подробнее, оказалось что всё не так радужно, как кажется.
Да, серебряной пули нет :)
Самое больное — это если нужно расширить хранилище (с 2 до 3, с 3 до 4 дисков и т.п.), то это выходит дорого и неудобно, потому что в отличие от mdadm в RAIDZ нельзя добавить новое устройство — надо куда-то слить данные, которые лежат и заново создавать пул.
Расширение пула — самая что ни на есть штатная операция, наращивается новыми vdev устройствами (mirror, stripe, raidz). Для stripe всё даже круче — можно на лету добавить диск и сделать mirror. Да, сейчас в raidz нельзя просто так добавить диск, но работы в этом направлении ведутся тыц и тыц.
Плюс к этому всегда есть возможность на лету (!) увеличить любой vdev, заменив его диски на большие размером.
Ещё есть тревожные звоночки от людей, которые заменяли диски в пуле, у которых число секторов было меньше, чем в исходных.
Ну тут вообще нет претензий к ZFS. Как и в мифе про требование ECC памяти — оно может стрельнуть в ЛЮБОЙ ФС и менеджере дисков. А ZFS, как раз таки, по умолчанию создаёт 8МБ доп. пустой раздел, чтобы иметь манёвр на такой случай.
Судя по тестам (правда, чужие бенчмарки — это бабка надвое сказала), COW довольно сильно просаживает скорость чтения/записи.
На самом деле с производительностью всё нормально, если понимать особенности работы ZFS. Она в первую очередь обеспечивает безопасность данных, и вот тут да, мы будем получать накладные расходы в виде случайной записи-доступа и минимум 2 копий метаданных. При должной настройке во многих кейсах ZFS делает других. Во многих он также по умолчанию хуже :)
Также стоит понимать, что все плюшки ZFS используют ресурсы CPU по умолчанию больше, и при использовании всяких NVME полную скорость дисков выжать очень сложно (банально потому, что можно раньше упереться в CPU). Но это и не был первоначальный кейс ZFS, он затачивался под HDD, где задержки позволяют успеть сделать многое в CPU. Если кому интересно — тут как раз обсуждают и думают, как можно оптимизировать pipeline ZFS для NVME.
На самом деле (тут конечно наверняка палками побьют любители ZFS), почти всё можно реализовать средствами линуксовых dm/md — это lvm, mdadm, luks, vdo и т.п…
Можно собрать только отдалённо похожее, и по мере сборки производительность быстро упадёт ниже показателей ZFS, ну и аналога ARC кеша в принципе нет. А собрать аналог нельзя, потому что все эти layerы, кроме ext4/xfs/whateverFS не будут знать о данных. А вот здесь ZFS за счёт знания о данных и ARC/ZIL pipeline отлично оптимизирует производительность и даёт не плохие цифры.
Повторюсь — у разных инструментов разные цели. Брать ZFS и требовать от него только производительности, не изучив а на что он эту производительность тратит — ну, такое.
Часто люди делятся также и на ещё не получавших кашу из данных и не сталкивавшихся с fsck ext4/xfs, и на тех, кто уже пользуется ZFS :)))) Я готов отдать немного процентов производительности за целостность, атомарность, удобство использования, снапшоты, сжатие на лету, mirror/raidz и многое другое.
Спасибо за развернутый комментарий.
Можно собрать только отдалённо похожее
Безусловно, речи и не шло о том, что можно сделать ZFS, но круче, дешевле и проще. Самая главная проблема, как вы упомянули, это надёжность данных. Не могу сказать, как сейчас обстоит дело, но раньше возникали ситуации, при которых раздел в LVM мог умереть, если в RAM были незаписанные данные и отключилось питание.
Это конечно в какой-то мере нивелируется установкой ИБП, но звучит довольно дико.
Плюс к этому всегда есть возможность на лету (!) увеличить любой vdev, заменив его диски на большие размером.
Это довольно дорого, при этом нужно обновить все диски, при этом старые, которые работали 24/7, уже особо некуда деть. В случае с несколькими зеркалами из пар одинаковых дисков это относительно адекватно (если есть лишние интерфейсы для подключения), но если используется RAIDZ1/2/3, там придётся менять всё сразу. А для этого нужно x2 дополнительных портов для подключения помимо самих дисков.
Если нет необходимости никак расширять пространство — тогда да, ZFS отличная ФС (это не сарказм, для домашнего использования вполне нормальный юзкейс), но в некоторых нюансах слишком дорогая выходит. Правда, надеюсь всё же, что к тому моменту, как лично мне понадобится дополнительное место — в ZFS всё же поддержат расширение RAIDZ (:
Часто люди делятся также и на ещё не получавших кашу из данных и не сталкивавшихся с fsck ext4/xfs, и на тех, кто уже пользуется ZFS
Если люди полагаются только на целостность ФС и хранят важные данные в одном экземпляре — их не спасёт ни ZFS, ни магнитная лента, ни запекание лазером в алмазе. В данном случае, если нет другого дубликата данных — это ружьё, которое выстрелит, но когда-то потом. Серебряной пули действительно нет, но приятно что разработчики ZFS хотя бы двигаются в этом направлении.
Если люди полагаются только на целостность ФС и хранят важные данные в одном экземпляре — их не спасёт ни ZFS, ни магнитная лента, ни запекание лазером в алмазе. В данном случае, если нет другого дубликата данных — это ружьё, которое выстрелит, но когда-то потом. Серебряной пули действительно нет, но приятно что разработчики ZFS хотя бы двигаются в этом направлении.
Единственно добавлю, что по умолчанию из всех ФС только ZFS сейчас проверяет целостность данных. Никто не говорил, что после этого бекапы не нужны. Но только в этом случае вы хотя бы явно узнаете, что ваши данные в бекапе всё ещё не превратились в кашу.
btrfs умеет проверять суммы данных — https://btrfs.wiki.kernel.org/index.php/FAQ#What_checksum_function_does_Btrfs_use.3F и вроде по умолчанию включено.
В ext4 — только по метаданным — https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
+"Data checksums" https://en.wikipedia.org/wiki/Comparison_of_file_systems#File_capabilities
HAMMER NOVA NILFS ZFS Btrfs ReFQ SquashFS
ext4 — повреждение данных при этом пройдёт для вас незаметно, если правильно помню.
HAMMER NOVA NILFS ZFS Btrfs ReFQ SquashFS
Что из этого стабильно, доступно как RW ФС на Linux, кроме ZFS и btrfs? Не поймите меня не правильно, я буду только рад, если и другие ФС будут уметь такое.
Можно собрать только отдалённо похожее, и по мере сборки производительность быстро упадёт ниже показателей ZFS
Вести с полей: в целом, вы оказались правы. ZFS raidz1 с ashift=12 выдаёт на 40% (!) большую скорость записи на обычных SATA HDD, чем аналогичный RAID5 (mdadm с lvm разделами поверх) на абсолютно идентичной системе.
Стоит понимать, конечно, что это порядки ~40-50МБ/с и 40% — не прямо-таки гигантские числа, но разница в копировании терабайтов информации исчисляется часами в таком случае.
Вот бы еще ZFS поверх VDO запустить…
Смысл в том, чтобы сжатие и дедупликацию переложить на VDO, а ZFS оставить только вычисление CRC.
Allocation classes — у vdev массивов появился тип носителей, теперь можно вынести хранение метаданных/таблиц дедупликации(DDT)/блоков данных менее Х Кбайт на отдельный vdev массив из более производительных дисков
теперь непонятно нужно делать special, l2arc, или и то, и другое )
нашлось только https://github.com/zfsonlinux/zfs/issues/7743
Ну всё же задачи у них разные, как и требования к резервированию, special class диски персистентны и их обязательно нужно резервировать.
А l2arc лучше обычно заменить добавлением озу.
Касаемо issue — проблема сейчас только в том, что данные со special class vdevs тоже будут кешироваться в l2arc. Если вам очень нужны оба — это не так критично, т.к. Метаданных по сравнению с данными всё равно сильно меньше.
Ну всё же задачи у них разные
задача, если смотреть глобально, одинаковая — "сделать быстро".
с secondarycache=metadata l2arc решает задачу вымывания метаданных из кэша, но
- кэширует только чтение;
- жрёт ОЗУ.
А l2arc лучше обычно заменить добавлением озу.
вот-вот.
ИМХО если вспомнить, что "холодное" обращение к данным требует несколько обращений к метаданным, что обращение к метаданным — это случайный доступ мелкими блоками (самый болезненный сценарий для hdd), то становится понятным, что special allocation class — киллер-фича.
задача, если смотреть глобально, одинаковая — «сделать быстро».
Обобщение очень похоже на кнопку «Сделать хорошо», уж извините за сравнение :)
с secondarycache=metadata l2arc решает задачу вымывания метаданных из кэша
Эм, не приходит в голову кейс, когда нужно так делать. Уж лучше наоборот — primarycache=metadata и secondarycache=all, класть на l2arc только мету — уж лучше её держать в ОЗУ, а L2ARC если уж есть, то отдать на всё остальное.
то становится понятным, что special allocation class — киллер-фича.
Согласен, только я не понял что вы хотели сказать, изначально ваш вопрос был, как я понял, «когда использовать l2arc а когда special vdev».
L2ARC скоро будет персистентным, его кейс чисто про кеширование чтения, и он с этим справляется отлично. Special vdev конечно дал новые возможности, но кейс для L2ARC остался.
ZFSonLinux 0.8: фичи, стабилизация, интриги. Ну и trim