После почти двух лет разработки представлен (https://zfsonlinux.topicbox.com/groups/zfs-announce/Td685d95...) релиз ZFS on Linux 0.8.0 (http://zfsonlinux.org/), реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Работа модуля проверена с ядрами Linux c 2.6.32 по 5.1. Готовые установочные пакеты подготовлены (http://zfsonlinux.org/) для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Кроме того, модуль ZFS on Linux уже входит в состав дистрибутивов Debian, Ubuntu, Gentoo, Sabayon Linux и ALT Linux.
В рамках ZFS on Linux подготовлена реализация компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre. Наработки проекта основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и исправлениями от сообщества Illumos. Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.
Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFS on Linux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра. Стабильность кодовой базы ZFS on Linux оценивается как сопоставимая с другими ФС для Linux.Основные изменения:
- Добавлена встроенная поддержка шифрования хранимых данных на уровне файловой системы и разделов. По умолчанию для шифрования используется алгоритм aes-256-ccm. Для загрузки ключей шифрования предложена команда "zfs load-key";
- Реализована возможность передачи шифрованных данных при выполнении команд "zfs send" и "zfs receive'. При указании опции "-w" уже зашифрованные в пуле данные передаются в другой пул как есть, без промежуточной дешифровки. При подобном копировании данные остаются защищены ключом отправляющей стороны, что позволяет использовать данный режим для резервного копирования на не заслуживающие доверия системы (в случае компрометации получателя, без ключа атакующий не сможет получить доступ к данным);
- Добавлена поддержка удаления первичных накопителей из пула хранения, подсоединённых как по отдельности, так и в составе зеркала. Удаление осуществляется командой "zpool remove". В процессе удаления данные с исключаемого накопителя копируются на остающиеся в пуле первичные накопители;
- Добавлена команда "zpool checkpoint" для сохранения текущего состояния пула с возможностью отката дальнейших изменений на сохранённый момент времени (создаётся снапшот всего пула). Представленная возможность может оказаться полезной в процессе выполнения потенциально опасных сложных административных работ, в обычных условиях приводящих к необратимым изменениям (например, активация флагов новой функциональности ZFS или очистка данных);
- Добавлена команда "zpool trim", позволяющая информировать используемые в пуле накопители о секторах, которые больше не используются. Применение операции TRIM даёт возможность повысить эффективность работы SSD-накопителей и предотвратить деградацию их производительности. Для включения непрерывного фонового процесса передачи команд TRIM предложено новое свойство "autotrim";- Добавлена команда "zpool initialize" для инициализации всего нераспределённого дискового пространства, что позволяет обеспечить его мгновенную готовность к использованию, без снижения производительности при первом доступе (например, при размещении виртуализированных хранилищ, таких как VMware VMDK);
- Добавлена поддержка аккаунтинга и квот на уровне проекта, дополняющих ранее доступных квоты на уровне пользователя и группы. По сути проекты - это отдельное пространство объектов, связанных с отдельным идентификатором (project ID). Привязка определяется через операцию 'chattr -p' или через наследование атрибутов. Для управления проектами представлены команды "zfs project" и "zfs projectspace", позволяющие управлять созданием проектов и задавать для них лимиты дискового пространства;- Добавлена возможность создания Lua-скриптов для автоматизации различных работ с ZFS. Скрипты запускаются в специальных изолированных окружениях при помощи команды "zpool program";
- Реализована новая библиотека pyzfs (https://github.com/ClusterHQ/pyzfs), предоставляющая стабильный API для администрирования ZFS из приложений на языке Python. Библиотека является обвязкой над libzfs_core и предоставляет идентичный набор функций, но применяет более близкие для Python типы;
- Обеспечена совместимость утилит arcstat, arcsummary и dbufstat с Python 3;
- Добавлена поддержка интерфейса ядра Linux для прямого Direct IO ( O_DIRECT), позволяющий обращаться к данным без буферизации и в обход кэша;
URL: https://zfsonlinux.topicbox.com/groups/zfs-announce/Td685d95...
Новость: https://www.opennet.dev/opennews/art.shtml?num=50730
В тексте ошибка : неподготвлены установочные пакеты для основных дистрибутивов Linux.
Ты лучше скажи на БТРе больше покататься уже не придётся?А что думают по этому поводу Зюзя и МееГо? КрасноШляпники понятное дело уже забили на БТРа.
В Сюсе как был БТР дефолтным для рута, так и остался.
>КрасноШляпники понятное дело уже забили на БТРа.Так шапки и сабж в упор не видят.
Они давят на lvm + xfs/..
И надо сказать этот подход вполне себе альтернатива сабжу.
Мало ли кто и на что забил? Не так давно кричали, что и танки не нужны. Однако btrfs очень даже рулит сейчас, а танки совершенствуют и танкистов учат. Ты учишься или балакаешь токма?
Подскажите, а FreeNAS перейдет на вот этот ZFS on Linux?
а куда он денется, если мы и были главным проталкивателем ненужно-мержа?!
> Подскажите, а FreeNAS перейдет на вот этот ZFS on Linuxперейдет со временем, так как FreeBSD свою ZFS разработку переключает на ZoL реализацию
ZoLoFB
> ZoLoFBнет, ZoF: https://github.com/zfsonfreebsd/ZoF
>> Добавлена встроенная поддержка шифрования хранимых данныхУиии, праздник к нам приходит!
Да, это на уровне датасетов и это вкусно.
>Да, это на уровне датасетов и это вкусно.Чертей, которые используют слово "вкусно" вне пищи, надо сажать на кол.
Насколько оно пригодно для использования на десктопах, а не серверах?
Последнее обсуждение, что я помню - дефолтные настройки ARC жрут слишком много памяти, а уменьшение ARC резко негативно влияет на производительность.
Всё верно, ZFS не десктопная система. Но задуматься стоит, если Вам нужно сжатие, т.к. на данный момент к сожалению только COW системы поддерживают сжатие. И ZFS, вероятно, меньшее из зол.
меньшее из ZoL
Лучшее сочетание сжатия и скорости сейчас обеспечивает zstd, а это пока только btrfs.
Не только. Еще reiser4.
https://blog.delouw.ch/2018/12/17/using-data-deduplication-a.../https://www.redhat.com/en/blog/look-vdo-new-linux-compressio...
> если Вам нужно сжатието пользуйтесь архиватором
И снепшоты тоже через 7zip делаются за раз...
Очень пригодно.
Делаем zfs_arc_max в 10% RAM, где RAM>20GiB и радуемся, радуемся.
Негативного воздействия на производительность - не наблюдаем.
значит, производительность вам была не нужна вообще.
> значит, производительность вам была не нужна вообще.С чего вдруг? Всё летает.
Причём если ОЗУ много (к примеру 2-4tb) для zfs может хватить и 7%-3% ОЗУ.
> значит, производительность вам была не нужна вообще.А zfs на десктопе не для производительности, а для удобства. Для производительности - SSD.
И по секрету скажу, у меня для L2ARC есть, на котором 200G для того, что может быть в ОЗУ, но не обязано.
И ещё по секрету скажу, ARC на zfs умеет освобождать память в адаптивном режиме. Потому на десктопе с RAM 32G и 10% под ARC после полудня втыкания в браузер может быть занятым в 300-500M.
> Потому на десктопе с RAM 32G и 10% под ARC после полудня втыкания в браузер может быть занятым в
> 300-500M.это значит что вы его таки доломали совсем. :-(
arc должен освобождаться только в одном-единственном случае - острой нехватки памяти в системе.
Точно так же, как это делает буферный кэш - иногда полезнее выбросить в своп нечто, что может и вообще никогда не понадобиться, но сохранить read cache. С чего он у вас уменьшается если 31.5 гига заняты непоймичем? (окей, там на самом деле еще 500 из них занимает abd, который вы не видите, но он есть, где еще 31?)l2arc - это, чаще всего, деньги, которые вы могли потратить на оперативную память, но потратили на фигню (он имеет смысл, когда память либо физически не лезет уже, либо когда ее больше по одним мнениям 128, по другим 256G из-за каких-то проблем реализации, которые авторы zfs решать не планируют, потому что у них стока нет ;-)
Кстати, рекомендую иметь в виду, что его индекс не выгружается и жрет место в оперативной памяти - всегда, вне зависимости от востребованности самого arc2.
>> Потому на десктопе с RAM 32G и 10% под ARC после полудня втыкания в браузер может быть занятым в
>> 300-500M.
> это значит что вы его таки доломали совсем. :-(Нет
> arc должен освобождаться только в одном-единственном случае - острой нехватки памяти в
> системе.
> Точно так же, как это делает буферный кэш - иногда полезнее выбросить
> в своп нечто, что может и вообще никогда не понадобиться, но
> сохранить read cache.Нет, на desktop он может не заполняться, потому-что это desktop - он может выключаться к примеру
> С чего он у вас уменьшается если 31.5
> гига заняты непоймичем? (окей, там на самом деле еще 500 из
> них занимает abd, который вы не видите, но он есть, где
> еще 31?)Ничем.
> l2arc - это, чаще всего, деньги, которые вы могли потратить на оперативную
> память, но потратили на фигню (он имеет смысл, когда память либо
> физически не лезет уже, либо когда ее больше по одним мнениям
> 128, по другим 256G из-за каких-то проблем реализации, которые авторы zfs
> решать не планируют, потому что у них стока нет ;-)Он имеет смысл, когда desktop выключается/включается. И вместо чтения с hdd, выполняется чтение нужных данных с ssd (l2arc).
> Кстати, рекомендую иметь в виду, что его индекс не выгружается и жрет
> место в оперативной памяти - всегда, вне зависимости от востребованности самого
> arc2.Надо проверять. Но для desktop который выключается - не критично.
> Нет, на desktop он может не заполнятьсяа, это может. У меня десктоп только виндовый, и ему вечно памяти не хватает (потому что не совсем и десктоп), и перезагружается не чаще раза в две недели. Линуксная система (ни разу не в метафоре десктопа) выключается пару раз в году, и ей есть что держать в кэше.
> Он имеет смысл, когда desktop выключается/включается. И вместо чтения с hdd, выполняется чтение
> нужных данных с ssd (l2arc).а оно его не обнуляет при перезагрузке? И, кстати, если не - сама эта перезагрузка будет изрядно быстрее, если индекс l2arc (причем какого-то, как я понял, гомерического размера) не перечитывать (нет ведь никаких гарантий, что эти данные вообще зачем-то нужны).
> Надо проверять.
это описано в доках оракла, и,по-моему, в доках фринаса, вместе с конкретными цифрами.
Есть ли в линуксе для этого инструменты - не в курсе, у меня-то это в top.но в общем это настолько странное и далекое от гайдлайнов использование, что я бы взял секундомер и померял типовые задачи этого десктопа (включая вкл-выкл, раз они частые) - отдельно с l2arc, отдельно с нормальной настройкой zfs (без ненужных ограничений) и без l2arc вообще
Будете мерять - положите куда-нибудь, это гораздо интереснее серверов с аптаймом по 450 дней.
>> Нет, на desktop он может не заполняться
> а, это может. У меня десктоп только виндовый, и ему вечно памяти
> не хватает (потому что не совсем и десктоп), и перезагружается не
> чаще раза в две недели. Линуксная система (ни разу не в
> метафоре десктопа) выключается пару раз в году, и ей есть что
> держать в кэше.Выключаю все приборы, кроме холодильника, когда покидаю жилище - соблюдаю технику безопасности. ;)
>> Он имеет смысл, когда desktop выключается/включается. И вместо чтения с hdd, выполняется чтение
>> нужных данных с ssd (l2arc).
> а оно его не обнуляет при перезагрузке? И, кстати, если не -
> сама эта перезагрузка будет изрядно быстрее, если индекс l2arc (причем какого-то,
> как я понял, гомерического размера) не перечитывать (нет ведь никаких гарантий,
> что эти данные вообще зачем-то нужны).l2arc, обнуляет, патчей ещё не завезли (хотя я пробовал их применять). Я неправильно написал - при выключении/включении имеет смысл наличие на ssd метаданных.
$ zpool status tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 13h48m with 0 errors on Sun May 12 14:12:57 2019
config:NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
wwn-0x5000039fe6d37a87 ONLINE 0 0 0
wwn-0x5000c50079c65faf ONLINE 0 0 0
logs
wwn-0x5707c181003b37e5-part1 ONLINE 0 0 0
cache
wwn-0x5707c181003b37e5-part2 ONLINE 0 0 0> Будете мерять - положите куда-нибудь, это гораздо интереснее серверов с аптаймом по
> 450 дней.Если найду время, то может быть.
> У меня десктоп только виндовыйа я-то все понять не мог, что с тобой не то...
Как по мне, для десктопа и xfs вполне годится. Несколько лет использую, правда, не как корневую, а для хранилища. Корневую под Linux, всё-таки, целесообразнее в ext4 форматировать. Хотя.. на вкус и цвет товарищей net :)
*а если учесть, что со времён ext2 ни с одной, ни с другой не было ни одного серъёзного сбоя, то, наверное, по этому поводу и париться сильно не стоит.
Разве что, из исследовательских интересов ;)
**и суток не прошло:))
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....***с другой стороны, лично я, ни lvm, ни dm-crypt, ни Samsung SSD как-то пользуюсь :)
****а btrfs и подавно ...в смысле, не))
пригодно, ибо поломано одинаково что для тех, что для других.> Последнее обсуждение, что я помню - дефолтные настройки ARC жрут слишком много памяти
шок, сенсация - дефолтные настройки ядра линукса жрут вообще всю память, без всякой zfs!
total used free shared buffers cached
Mem: 8160616 8014792 145824 0 63352 6920316
-/+ buffers/cache: 1031124 7129492
представляете - 7 гиг сожрали, полтораста мегабайт всего оставили нужным и полезным задачам!
Так и должно быть. Свободная память - выброшенная в мусорное ведро память. Линукс - это вам не винда. Которая любит не использовать RAM и дурочки радуются, что якобы меньше ест :D
> Так и должно быть. Свободная память - выброшенная в мусорное ведро память.молодец, садись, четыре-с-минусом.
На пять-с-плюсом надо было сообразить, что с arc все должно было быть точно так же, причем buffer cache при этом должен быть в районе нуля, поскольку повторное кэширование да еще поверх более адекватного механизма - только лишняя латенси и лишний шанс поймать мусор (вроде бы тут у ZoL все правильно).
Поэтому твои затеи с его ограничением - во-первых, глупость, во-вторых, еще и работают не так как ты думаешь. (к сожалению, удобный инструмент для проверки, как на самом деле используется память, в линуксе отсутствует)
P.S. у винды все нормально с кэшированием, уж по сравнению с твоим отбалдовым "отрезать 20%, остальное потратить хз на что", но оно работает тоже немного не так как показывает process manager.
Поскольку предполагается, что юзеру не это знать надо, он хочет знать, сколько памяти осталось для его задач.
а, пардон - это, оказывается, [слово запрещенное на впопеннете] предлагал ручные ограничения ARC, а не пингвин. Звиняйте, что-то сегодня все анонимы кажутся на одно лицо.
Винда использует память точно также, вся свободная память уходит под кеш ФС
не разрушайте лап4атым мирок
тем более что юзероориентированные средства избавляют от лишних знаний, а более сложные ими ниасилены.
ну не совсем... далеко не совсемесли установлен SQL Server то именно он все сожрет а не винда
а если подобной софтины нет, то винда не жрет всю память под дисковый кеш
по моим наблюдениям не более 3/4
линукс съедает все что есть, притом сам занимаем копейки 500-1500 MB вся система в зависимости от конфига
> это вам не винда. Которая любит не использовать RAM и дурочки радуются, что якобы меньше ест :DХорошая альтернативная вселенная...
Смотря какие требования к декстопу. Можно и видео хранить, можно и нагрузку давать какую-то. Обычно на декстопе надо спип и хибернейт и неплохо бы чтобы рут был тоже на зфс при этом. Как с этим хз.
как обычно - нужен disk-backed sleep - нужен своп, своп на zfs работает только у solarisесли вы склонны считать его пережитком прошлого, то все более-менее будет работать. Но зачем?
всмысле "только у solaris" ?
ну в смысле у него он работает, а у остальных как обычно.судя по тому что даже proxmox его выпилила - что-то там совсем не так.
> Смотря какие требования к декстопу. Можно и видео хранить, можно и нагрузку
> давать какую-то. Обычно на декстопе надо спип и хибернейт и неплохо
> бы чтобы рут был тоже на зфс при этом. Как с
> этим хз.хибернейт обычно только на переносных пк нужен. на десктопе sleep достаточен обычно.
btrfs дома удобней. И не только дома.
>Добавлена команда "zpool trim",БСДшники уже успели утянуть к себе. Авторы коммитов TRIM теперь и в коммитах бсдшного ZFS мелькают (((
Пустили козлов в огород (((
Ровно наоборот. TRIM во FreeBSD лет 5 уже точно есть.
> Ровно наоборот. TRIM во FreeBSD лет 5 уже точно есть./usr/src % uname
FreeBSD
/usr/src % git log sys/cddl/contrib/opensolaris/
commit 618888b019e4005dec19c1688531e25d6ff63c76
Author: pjd <pjd@FreeBSD.org>
Date: Sun Sep 23 19:40:58 2012 +0000
Obtained from: zfsonlinux
Submitted by: Etienne Dechamps <etienne.dechamps@ovh.net>git логи не могут врать!
БСДшники как раз эту фичу запилили. Анон не в курсе о слиянии FBSD-ZFS с ZoL?
Поддержка TRIM взята из IllumOS. Слияние произошло в другую сторону. В BSD была своя реализация.
> БСДшники как раз эту фичу запилили. Анон не в курсе о слиянии
> FBSD-ZFS с ZoL?https://github.com/freebsd/freebsd/commit/618888b019e4005dec...
Читай по слогам:
> Add TRIM support.
> Obtained from: zfsonlinux
> pjd authored and pjd committed Sep 23, 2012Еще?
https://github.com/freebsd/freebsd/blob/edc77597c1be66d77328...
# $FreeBSD$
.PATH: ${SRCTOP}/sys/compat/linuxkpi/common/srcKMOD= linuxkpi
SRCS= linux_compat.c \
linux_current.c \
linux_hrtimer.c \
linux_idr.c \
linux_kmod.c \
linux_kthread.c \
linux_lock.c \
linux_page.c \
linux_pci.c \
linux_radix.c \
linux_rcu.c \
linux_schedule.c \
linux_slab.c \
linux_tasklet.c \
linux_usb.c \
linux_work.cШах и мат, врунишки. Ничего вы не умеете сами делать, только копипастить.
Читай по слогам:
> Add TRIM support.
> Obtained from: zfsonlinuxосталось рассказать нам - что ж там, откуда оно "obtained" - оно нихрена не работало ровно до версии 0.8 ?
https://github.com/zfsonlinux/zfs/commit/1b939560be5c51deecf...
что ета, блжад?
Машина времени завезла этот (точно этот?) код в 2012й год?
> https://github.com/freebsd/freebsd/blob/edc77597c1be66d77328...ой, все.
(ди6ил нашел линуксный эмулятор. Ни разу не gpl, и ни одного куска кода линукса не содержащий - как, впрочем, и zol - но код он не умеет, он умеет только текст)
> осталось рассказать нам - что ж там, откуда оно "obtained" - оно нихрена не работало ровно до версии 0.8 ?Например, потому что посчитали недостаточно оттестированым.
Кто же виноват, что бсдшники любят обмазываться свеженьким?> https://github.com/zfsonlinux/zfs/commit/1b939560be5c51deecf...
> что ета, блжад?
> Машина времени завезла этот (точно этот?) код в 2012й год?Какие-то непонятные виляния бсдшников после того как их ткнули носом в лог?
>> https://github.com/freebsd/freebsd/blob/edc77597c1be66d77328...
> ой, все.
> (ди6ил нашел линуксный эмулятор. Ни разу не gpl, и ни одного куска кода линукса не содержащий - как, впрочем, и zol - но код он не умеет, он умеет только текст)О GPL и коде в эмуляторе бсдшник неплохо придумал и оспорил с плавныи и отвлекающим переходом на личности.
Но там просто ткнули в эмулцию линуха, которая позволяет использовать его же наработки и дрова.
Если бы бсдшник видел свой фетиш не только в пуссиэкзе, он бы обратил внимание на подгрузку модулей linuxkpi.ko и linuxkpi_gplv2.ko, которые в свою очередь используют для подгрузки дров "скопипи*женных" прямиком из линукса.
https://www.freshports.org/graphics/drm-current-kmod/
> DRM modules for the linuxkpi-based KMS components
> amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components.Currently corresponding to Linux 4.16 DRM.
Но с десяточки видимо видны далеко не все нюансы.
> Например, потому что посчитали недостаточно оттестированым.или потому что это был плохоспортированный кусок недоделанного ораклово-сановского, который не работал и не мог?
во фре он массово работал еще пять лет назад - что было весьма полезно лучшей-ос-для-запуска-в-вмвари, ага, там это важно.
> Какие-то непонятные виляния бсдшников после того как их ткнули носом в лог?
как только вы покажете лог ZoL с таким же коммитом - так и будем вас слушать. А пока у вас ссылка только на текст что "взято непоймиоткуда из проекта zol" - на сарае написано, а там - дрова.
Оно может и вовсе просто обсуждалось где-нибудь в рассылках или что там у них был за чятик в 12м году вокруг ZoL, и в дерево не попало совсем.
Вот куча правок с характерными именами разработчиков несколько месяцев назад - да, попала, конечно же это совпадение. (впрочем, еще больше там закрыто из-за недостатка времени у этих разработчиков, им, похоже, гоняться за движущейся мишенью надоело)> Но там просто ткнули в эмулцию линуха
там просто нашли слово линух. Пока я вам не сказал, вы явно не поняли что это эмулятор - ридмишечкиmd не нашлось, да?
ну да, kms позаимствован из линуха - авторы иксов же доломали окончательно собственную поддержку драйверов, вы предлагаете freebsd заняться за них написанием и этого с нуля? И да, на сервере они нафиг не сдались.
зато как крякали и гузками когда-то трясли - "посмотрите, посмотрите - у nt4 - графика в ядре, какой позор!"
> Пока я вам не сказал, вы явно не поняли что это эмуляторНе тот ник у вас, ох не тот!
В справке о рождении следы затирания Artagnan не видны? И никакая Вангелия П. в родственниках не числилась?Самому что-то придумать, приписать опонненту и усердно оспаривать.
Впрочем, ничего иного от бсдшников не ожидалось.
> ну да, kms позаимствован из линухаО чем и шла речь:
>> Ничего вы не умеете сами делать, только копипастить.И стоило так вилять, чтобы в конце все же признать?
В чом принцыпиальное отличие ZFS от BTRFS, кроме костылей у 1й?
zfs send -R -i snapN-1 zpool/fs@snapN | zfs recv zpoolNEW/fs
вообще, рекурсивные операции со снэпщотами в BTRFS есть ? Нету ? Ну и как мне атомарно скопировать 100500 докер контейнеров на BTRFS на другой хост ?
блок девайсы и снэпшоты блокдевайсов BTRFS хоть когда-то будет поддерживать ? Нет ? Не надо ничего говорить об lvm-thin. Самии хороните свои данные на этом хрупком говне.
И та и другая - COW. И та и другая существенно медленнее на широком спектре операций, относительно обычных файловых систем. Разница между ними в структуре хранения данных. BTRFS буквально виснет в некоторых сценариях. При работе виртуалки, например. ZFS более менее вытягивает любые нагрузки. Но при этом требует много памяти (от двух ГБ и более). Её конечно можно посадить на диету, но тогда уже существенно просаживается производительность...
Надо понимать, что COW файловые системы предназначены для файлопомоек. Виртуалки/базы данных и COW не совместимы.
>ZFS более менее вытягивает любые нагрузки. Но при этом требует много памяти (от двух ГБ и более). Её конечно можно посадить на диету, но тогда уже существенно просаживается производительность...Не жалко если для дела.
>BTRFS буквально виснет в некоторых сценариях.Бывало...
>Надо понимать, что COW файловые системы предназначены для файлопомоек. Виртуалки/базы данных и COW не совместимы.Да вкурсе. Но не в курсе чо при жостком REBOOT настройки плазмы сбрасываются на BTRFS, вроде в обычных конфигах хранятся, а не в db.
Ты тихо потерял постоянно перезаписываемый файл. Это плохо.
это нормально. Ненормально когда вместо файла мусор или fs "громко" вопит "чтотапаламалася" и не работает.
> при жостком REBOOT настройки плазмы сбрасываютсят.е плазма постоянно держит конфиг открытым на запись? :facepalm:
что_же_с_нами_стало.jpg
>медленнее на широком спектре операций, относительно обычных файловых систем.безусловно
>BTRFS буквально виснет в некоторых сценариях. При работе виртуалки, например.
не встречался. в настоящий момент у меня на 3 серверах на btrfs живёт 4 виртуалки (qcow2/kvm) и с десяток контейнеров. Нагрузка весьма приличная.
btrfs смонтирована с autodefrag,commit=120. проблем (в том числе, при жёстком останове при проблемах с питанием), за 4 года, не было.экспериментально (да. идиотизм. проба ради частых снепшотов), на btrfs, живёт база 1c (postgresql). Опции монтирования те же. Проблем (тьфу-тьфу, пока!) не было.
> Виртуалки/базы данных и COW не совместимы.А мужики-то не знают...
ZFS - система не для серввера, и тем более - не для настольного ПК, это система для полноценной СХД - с FC/iSCSI+10GbE и прочими плюшками.
> ZFS - система не для серввера, и тем более - не для настольного ПК, это система для полноценной
> СХД - с FC/iSCSI+10GbE и прочими плюшками.дружище, полноценные схд с fc (iscsi немодно уже 20 лет) покупают за денежки (самосвалами) и очень маловероятно что внутри окажется zfs.
Ну как-то так судя по тому как проявляют себя в работе.
zfs - система прежде всего для наколенных поделок на ту же тему но чтоб "денег никому не платить", и у большинства ее потребителей никакого fc/10ge нет и не предвидится - и денег нет нах, и не нужно ни для чего вообще.
Единицы собирают себе полноценные хранилки для дома для семьи именно такого типа (я аж двоих лично знал) - но кому дома нужен ревущий монстр, жрущий как не в себя, да еще и есть чего к нему подключить с другой стороны?
Дружок... как бы тебе сказать, но... хранилки с FC и ZFS есть например в нашем ВПК. И немало. NetApp, EMC и прочие - в сильной немилости по очевидным причинам. :)iSCSI - опять в моде, по причине появления 40Gb с ее rdma и фишками для low latency
Для дома для семьи за глаза хватает поделок а-ля OMV.
> хранилки с FC и ZFS есть например в нашем ВПКв вашем впк два солдата и лопата заменяют экскаватор (а то ж его немцы разрабатывали, низя-низя по очевидным причинам, а у китайского клона опять лопнул гидравлический циллиндр)
но к вам на встречу уже бежит (педобиржпг) очень-плохая-дорога со своим ocean store. Он-то, кстати, наверное и работает даже.
> iSCSI - опять в моде, по причине появления 40Gb с ее rdma и фишками для low latency
про fcoe в вашем впк, видимо, не слышали, и продожают бережно полировать дедушкин велосипедик, теперь вот с реактивным двигателем на багажнике. Интересно, свитчи для него и сетевые карты тоже в твери в подвале собирают, или все же у проклятого империалиста приходится покупать (плача и истово крестясь) ? Плохая дорога, помнится, в 40G умела "не очень".
никакой "low latency" на iSCSI не будет, by design не предназначен он для этого. Вот лопнуть обожравшись вполне может.
Ну, впрочем, это и есть уровень использующих наколенные поделки на любительского уровня технологиях в ВПК. Ни разу и не жалко, разумеется, смотрите только подвиг главного инженера космодрома Сточный не повторите - в тюрьме опеннетика не будет.
Дома, кстати, они разные бывают. У некоторых, не буду пальцем показывать, дома как раз вполне полноценная хранилка с rdma и прочими радостями - но там владелец дома не стеснялся в свое время тыкать носом разработчиков zfs в баги и глюки. Для чего, естественно, нужна квалификация, которая у него-то есть. А в вашем впк таких людей нет и не будет.
Ну и какие преимущества у FCoE перед iSCSI? Да правильно - никаких, ибо ограничения на 95% накладываются Eth, а не протоком блочного доступа к устройству. Ну и куча проблем с поддержкой, в том же линаксе как например. А вот iSCSI - поддерживает каждая лопата.> А в вашем впк таких людей нет и не будет.
Мне предлагали работать в одной очень крупной американской фирме, с переездам туда, оформление берет на себя работодатель. Отказался - не выгодно. Да яб там находился в категории "высший средний класс", но по факту - это примерно в полтора раза меньше чем я получаю в ВПК здесь.
> У некоторых, не буду пальцем показывать, дома как раз вполне полноценная хранилка с rdma и прочими радостями - но там владелец дома не стеснялся в свое время тыкать носом разработчиков zfs в баги и глюки.
ну у меня дома стойка, в которой много чего интересного... rdma правде нет - не надо мне. Но если вдруг понадобиться - будет :) Зарплата, которую я получаю работая на ВПК - позволяет. :)
Для vdev же cow не используется? Т е виртуалка на этом виртуальном диске нормально работает?
В моих тестах примерно в скорость дисков упирается все.
>И та и другая - COW.Жаль только zfs не умеет в reflink. А держать включенной дедупликацию бывает накладно
а обычные линки чем вам не угодили? reflink - костылик в основном для доскеров и им подобным (ну и не считая того что других снапшотов у btr таки нет)
> Жаль только zfs не умеет в reflink.оракловая умеет.
ZFS и BTRFS системы специального назначения. Их плюшки нужны ну единицам пользователей. Тем более, что плюшки предоставляются не за бесплатно.
> ZFS и BTRFS системы специального назначения. Их плюшки нужны ну единицам пользователей.
> Тем более, что плюшки предоставляются не за бесплатно.А если я хочу гарантировано защититься от проблем снапшотом всей ФС?
А потом ещо и на другой HDD бекапить инкрементально через
btrfs send -p /BTR4/@2014 /BTR4/@2019 | btrfs receive /backup/
?
7zip
> 7zipЭто совершенно по нубски, хотя б tar.
btrfs весьма не плоха как замена ext4, даже если вы не пользуетесь её "плюшками", потому что она сохранит ваши данные, в то время как ext4 потеряет.
> потому что она сохранит ваши данные, в то время как ext4 потеряетс чего бы?
скорее она сохранит свою консистентность, ценой отправки подлежащих (возможно) восстановлению данных в /dev/null, а ext4 предоставит прекрасную возможность потрахаться по настоящему, но чаще всего это не требуется, и вообще никто не замечает каких-то там отвалившихся линков в /tmp или в .tormozilla/гдеонотам/cacheа вот превращений всей ext4 в тыкву, приводящую к kernel panic - что случается с zfs, пока не видали.
imho, если не пользоваться ни redundancy, ни снапшотами, ни простым удалением-добавлением устройств - нафиг не надо лишних сложностей.
У меня другая практика. Полностью противоположная. btrfs ломается несмотря на raid-массив на совершенно исправном оборудовании.
В том, что первая не теряет данные.
> В том, что первая не теряет данные.100%?
А потерю даных в BTRFS подтверждаю - не COW, а БЫК какой то.
>> В том, что первая не теряет данные.
> 100%?пул иногда в тыковку превращается, и ты получаешь прекрасную возможность удалить их самостоятельно.
а так чтоб просто вот взяло и потеряло и дальше поехало - такого, вроде, не замечено.
но с zfs send "все не так однозначно!"
О да, прям имперические данные, открывшие нам глаза! А на самом деле, скорее, показавшие твою глупость, ибо твоё мнение -- мнение одно человека и без всякого подтверждения.
> О да, прям имперические данные, открывшие нам глаза! А на самом деле,
> скорее, показавшие твою глупость, ибо твоё мнение -- мнение одно человека
> и без всякого подтверждения.В отличии от очередного анонима мои слова утверждены моей аватаркой.
Доказывать анониму я ничего не собирають, потому шо тебя не существует.
> империческиеКакие? Имперские?
Это еще большой вопрос, где большие костыли.
Например zfs есть за пределами линукса. Это вообще странно что с переносимостью между системами в 2019 такая беда
> Например zfs есть за пределами линукса.но пользы от этого нет никакой, ибо она не смонтируется.
> Это вообще странно что с переносимостью между системами в 2019 такая беда
ext4 прекрасно переносится везде, кроме линуксов и фрей (где реализация через fuse немношк неэффективна и ненадежна, а native in-kernel, ВНЕЗАПНО, несовместима с той же самой версией созданной на другом процессоре)
ntfs прекрасно переносится везде, кроме мабилок, где намеренно выпилена.
exfat прекрасно переносится везде, включая мабилки самсуня с native driver
>> Например zfs есть за пределами линукса.
> но пользы от этого нет никакой, ибо она не смонтируется.И давно? Помню, монтировал пулы от ZoL 0.6.x в FreeBSD, делал scrub.
> И давно? Помню, монтировал пулы от ZoL 0.6.xда у вас, дедуля, хорошая память. Вы бы еще пул версии 3 вспомнили.
А у нас оно нонеча - вот так:
https://www.opennet.dev/openforum/vsluhforumID3/117164.html#198- и это, сами понимаете, цветочки, когда симпортится - полезут ягодки
>> И давно? Помню, монтировал пулы от ZoL 0.6.x
> да у вас, дедуля, хорошая память. Вы бы еще пул версии 3
> вспомнили.Енто ещё что, помню даже поимённо всех анонимов Опеннета.
> А у нас оно нонеча - вот так:
> https://www.opennet.dev/openforum/vsluhforumID3/117164.html#198Дык, завтреча пропатчат ZoL во FreeBSD.
> - и это, сами понимаете, цветочки, когда симпортится - полезут ягодки
Ягодки в хозяйстве зело нужное, витаминчики пользительны для памяти.
> Дык, завтреча пропатчат ZoL во FreeBSD.ну и зачем мне два одинаковых?
смысл-то был пока они были разные.
Никакого смысла в том, что они разные. Весь смысл именно в том, чтобы поведение было одинаковое и ожидаемое
ну и зачем мне одинаковые ожидаемые тормоза по cpu, write amplification и неконтролируемый отжор памяти abd ?"разные" позволяли как-то подобрать наименее поганый вариант под текущую задачу.
>> Дык, завтреча пропатчат ZoL во FreeBSD.
> ну и зачем мне два одинаковых?Тебе зачем? А мне зачем мне думать за тебя?
Шикарно! Обожаю zfs. Не самая шустрая зато удобнее некуда. Осталось прилумать как на нее целиком перелезть
> Осталось прилумать как на нее целиком перелезтьА в чом проблема?
> Осталось прилумать как на нее целиком перелезтьА зачем - "целиком"?
Тем и хорош выбор, что для разных задач можно применять разные инструменты.
"Топором мы всё могём"? Это тут не подходит.
ZFS хорош для своих задач, ReiserFS - для своих задач, XFS - для своих, EXT4 - для своих.
А универсальность - это всегда "всего понемножку, но ничего на всю катушку".
Ну не будешь ведь ты писать текстовые документы в графическом или музыкальном редакторе? А ведь можно! Но в текстовом процессоре это делать многим лучше.
ReiserFS уже давно ни для чего не хорош. Остановите некрофилию!
> ReiserFS уже давно ни для чего не хорош. Остановите некрофилию!А у тебя, небось, BTRFS во все поля? Или WinFS?
тогда сотни миллионов тех кто использует ntfs по вашему кто ?
> тогда сотни миллионов тех кто использует ntfs по вашему кто ?Черные археологи?
Если учесть, что ntfs -- наследие hpfs, то это чёрные некрофилы, потому что для своего времени hpfs была очень даже хороша, а ntfs её извратила, убила, а потом сдохла сама.MS вообще не может ничего сама сделать. Вроде бы выпустила refs, которая приближается хотя бы отчасти к zfs и btrfs, но даже эти потуги MS убивает своей криворукостью.
> Если учесть, что ntfs -- наследие hpfsэто сказки. От hpfs там нет практически ничего, кроме некоторых идей, с тем же успехом можно считать ее наследием fat (а чо, некоторые идеи - были). Да и не умела та практически ничего полезного - великое достижение, имена файлов подлиннее 8.3 (то есть то что любой unix на тот момент умеет уже лет двадцать).
> потому что для своего времени hpfs была очень даже хороша
а это просто вранье. Она даже по сравнению с fat была нехороша. Единственная существовавшая реализация была совершенно омерзительна. Как в силу родовой травмы своей операционной системы, безнадежно искалеченной по требованию IBM, так и в силу желания той же IBM продавать ее по два раза. Но, вероятно, и в силу архитектурной примитивности тоже.
> там нет практически ничего, кроме некоторых идейааааа, ну ок. теперь всё понятно.
повторяю для тугослышащих: еще больше там идей, уже реализованных в fat. Причем та их скопировала местами прямо из systemV/bsd - ни у кого другого на тот момент, afaik, иерархического дерева неопределенной глубины не было, кроме, может, лабораторных поделок.Результат же "испорченной" реализации - hpfs не имеющая толком write cache вообще - неминуемо что-нибудь портила при нештатном завершении работы (чаще всего прилетало в вечно-открытую на запись конфигурацию десктопа, редко-редко у кого он сохранял первозданный вид через год, но бывало что и перестановкой всей системы заканчивался банальный сбой питания - причем с установленными на fat такого не происходило, клятая майкрософт нагадила). Винду перезагружают reset'ом миллионы криворуких пользователей - и в худшем случае теряют открытый документ ворда, который ворд сам же и восстановит потом.
Слава ебеме! Вот кто умеет разрабатывать ос и фс, а не те кто вы подумали!
>Результат же "испорченной" реализации - hpfs не имеющая толком write cache вообще - неминуемо что-нибудь портила при нештатном завершении работы (чаще всего прилетало в вечно-открытую на запись конфигурациювы о какой версии hpfs/оси говорите?
по опыту работы с Авророй (да и Мерлином), осталось стойкое воспоминание о практической неубиваемости фс. А уж размещение central directory band в серёдке диска (куда, кстати, редко что "прилетало") и возможность восстановить хорошо почиканную фс сканированием штатным чекдиском...Да и про кеширование, не надо. Имелась возможность сравнить работу с ранними ntfs и стоящими рядом hpfs. Первые долго "хрустели" диском. Вторые -- "летали".
ну и наконец, про испорченную реализацию ntfs. Вы помните, что ранние варианты ntfs читались драйвером hpfs (но не наоборот?).
> вы о какой версии hpfs/оси говорите?warp3 (ну и все что было до того, начиная с 2.0 и заканчивая lanserver3). На этом я потерял к ней последние остатки интереса - windows2000 меньше тупила, была в сто раз удобнее в администреже (поскольку не требовала миллиарда мелких настроек для совершенно тривиальнейших вещей) и уже обросла изрядным количеством софта, для доса/win3.0 несуществующего (о native софте для "лучшей дос чем windows3.0" - помолчим)
причем при демонстрациях беты этой 3 - ебемер при ей приставленный перезагружал ее нагло ресетом, хитро улыбаясь - и десктоп у него не был битым. Глянули - а она у него на fat поставлена.
> Вы помните, что ранние варианты ntfs читались драйвером hpfs
ни разу не пробовал - то, на чем стояли "ранние варианты ntfs" было немного дороговатым, чтобы на нем эксперименты непонятного смысла проводить.
А когда я заполучил ту машину в свои руки - выяснилось, что в 95м году у ось-пополам нет bounce buffer. И 32мегабайта мне абсолютно не пригодятся - пришлось половину выкинуть. isa scsi, ага. Господи, как же она тупила... В сравнении с до того стоявшей там nt3.1, тоже, мягко говоря, не идеальной. И это ведь hpfs-почти-386, у которой хотя бы write cache уже было можно включить. Вручную, ага. Пользователи той винды со смеху бы подохли.Так что не надо мне сказочек про прекрасную осьдва. Вон, до сих пор в углу этот гроб стоит, плата только неродная. Пароль, правда, наверное уже не вспомню - несколько лет назад пробовал, хрен там.
>> Осталось прилумать как на нее целиком перелезть
> А в чом проблема?Android-x86 тяжело поставить в соседний подтом. :)
Линукс, фряха и соляра давно вроде успешно грузятся. У вас мак или ещё какой оффтопик?
А ОС с неё умеет загружаться в многодисковой конфигурации?У меня сейчас система на домашнем сервере загружается с btrfs в который включено 2 физических диска в режиме raid 1, на случай если один из них сдохнет, работа продолжится, после замены сломанного опять все поедет в 2х дисковой конфигурации. Интересно, zfs так умеет?
OS (ирония) с ZFS умеет загрудаться
умеет, https://wiki.gentoo.org/wiki/User:Fearedbliss/Installing_Gen...
Но не особо нужно это.
ОСь грузить с SSD с ext4, а /{home,var,opt,usr/local,srv} с zfs в mirror или raid-z/z1/z2/z3 и радоваться, радоваться.
именно для / (и возможно прилегающих к нему /var) только и нужна возможность отката на снапшот.
Для остального существуют архивы и бэкапы.Но вы продолжайте сооружать бессмысленные гибриды ужа с ежом.
> именно для / (и возможно прилегающих к нему /var) только и нужна
> возможность отката на снапшот.
> Для остального существуют архивы и бэкапы.Зависит от ОС, если у вас Debian или RHEL и производные, то да, snapshot не помешает для корня.
Но на практике - снять/отресторить backup корня проще (мало занимает), чем возиться со снапшотами при сломавшемся буте с zfs.> Но вы продолжайте сооружать бессмысленные гибриды ужа с ежом.
Гибриды не бессмысленные, проверено.
> Но на практике - снять/отресторить backup корня проще (мало занимает), чем возиться со
> снапшотами при сломавшемся буте с zfs.снапшоты нужны не для сломавшегося бута. Они нужны когда при апгрейде что-то поломалось и хочется не разбираться что там опять накуролесили, а просто вернуться в исходное состояние. Для btrfs это - поменять пару символов в командной строке grub, и потом из single еще раз то же самое в fstab - все, свежеустановленное можно даже и не удалять, потом в chroot будешь разбираться, что там пошло не так.
С zfs погеморройнее, поскольку bootenv'ы у нас не поддерживаются, а у них - кривые.
Но всяко на порядок быстрее и проще чем восстанавливать / с бэкапа (что-с происходит в этот момент, скажем, с базой установленных пакетов в /var/lib? Отож.)
>[оверквотинг удален]
> поломалось и хочется не разбираться что там опять накуролесили, а просто
> вернуться в исходное состояние. Для btrfs это - поменять пару символов
> в командной строке grub, и потом из single еще раз то
> же самое в fstab - все, свежеустановленное можно даже и не
> удалять, потом в chroot будешь разбираться, что там пошло не так.
> С zfs погеморройнее, поскольку bootenv'ы у нас не поддерживаются, а у них
> - кривые.
> Но всяко на порядок быстрее и проще чем восстанавливать / с бэкапа
> (что-с происходит в этот момент, скажем, с базой установленных пакетов в
> /var/lib? Отож.)btrfs или zfs в boot - первая имеет(имела???) свойство просто терять файлы, а со снапшотами ещё и деградировать в производительности в пол, со второй лишняя возня по настройке для boot'а. Проще маленький корень с ext4 на ssd.
Для экспериментов есть docker и libvirt, для работы есть etckeer.
А вот с /var/lib я и сказал, что нужны более развитые ОС - nixos например.
> btrfs или zfs в boot - первая имеет(имела???) свойство просто терять файлы/dev/sda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
17:33:36 up 35 days, 3:13, 1 user, load average: 0.65, 0.76, 0.81
(не смотрите на мелкие цифирки, это 24ядерный монстр, а рабочий день час назад закончен.)
нет, она, конечно, когда-нибудь грохнется, но не из-за этого, а из-за вот этого:
"graph": "/srv/docker",
угу, тоже btrfs, но еще не завтра, и я наивно надеюсь что грохнется именно тот том, он отдельный.zfs:
FreeBSD .local 11.1-STABLE FreeBSD 11.1-STABLE #14 r326974M: Thu Dec 21 11:51:08 MSK 2017
ну это конечно не время ввода в эксплуатацию, но время когда я там последний раз ведро сумел пересобрать, тоже довольно показательное.и таких корыт у меня сильно не одно, что первого, что второго типа.
Не то чтобы я доверял им что сильно уж ценное, но прям каждые пять минут - не, не падают.
>[оверквотинг удален]
> грохнется именно тот том, он отдельный.
> zfs:
> FreeBSD .local 11.1-STABLE FreeBSD 11.1-STABLE #14 r326974M: Thu Dec 21 11:51:08 MSK
> 2017
> ну это конечно не время ввода в эксплуатацию, но время когда я
> там последний раз ведро сумел пересобрать, тоже довольно показательное.
> и таких корыт у меня сильно не одно, что первого, что второго
> типа.
> Не то чтобы я доверял им что сильно уж ценное, но прям
> каждые пять минут - не, не падают.btrfs дома: 1 год использовал, пару раз вырубилось питание и пару раз было что повис комп из-за кривизны системной платы. Файлов и директорий недосчитался, причём в одном из случаев, недосчитался тех файлов к которым и обращений не было пару месяцев.
C zfs дома:
History for 'tank':
2017-12-10.18:09:40 zpool create -o ashift=12 tank /dev/disk/by-id/wwn-0x5000039fe6d37a87
2017-12-10.18:13:17 zfs create -o mountpoint=/mnt/homes tank/homes
2017-12-10.18:14:26 zfs set atime=off tank
2017-12-10.18:14:52 zfs set atime=off tank/homes
2017-12-10.18:15:07 zfs set relatime=on tank/homes
2017-12-10.18:15:14 zfs set relatime=on tank
2017-12-10.18:15:55 zfs set compression=on tank/homes
2017-12-10.18:18:04 zfs set compression=lz4 tank/homesЗа это время, и питание вырубалось, и зависания были и разгон и издевательства. Работает и ничего не исчезает. Память не ECC.
Что до linux и обновлений, установлено в 2016 году:
14:41 $ stat /srv/
File: /srv/
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 825h/2085d Inode: 1572866 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2019-05-04 22:30:22.227633903 +0300
Modify: 2016-01-06 12:42:48.215620792 +0300
Change: 2018-01-01 05:28:24.198335503 +0300Текущее ядро:
14:42 $ uname -a
Linux host 5.0.0-15-generic #16-Ubuntu SMP Mon May 6 17:41:33 UTC 2019 x86_64 x86_64 x86_64 GNU/LinuxВерсия zfs:
14:43 $ apt-cache policy zfs-dkms
zfs-dkms:
Installed: 0.7.12-1ubuntu5
Candidate: 0.7.12-1ubuntu5
Version table:
*** 0.7.12-1ubuntu5 500
500 http://ru.archive.ubuntu.com/ubuntu disco/universe amd64 Packages
500 http://ru.archive.ubuntu.com/ubuntu disco/universe i386 Packages
100 /var/lib/dpkg/status
Дружеский совет, забудте про raid-z/z1/z2/z3 и используйте зеркала. В случае помирания одного из дисков resilver занимает очень много времени и нагинает производительность по черному. Если учесть, что диски в массив покупаются в одно и тоже время, того же производителя, то велика вероятность, что в случае падения одного диска за ним последуют другие, а так как процесс востановления (resilver) занимает массу времени, то весь массив может накрыться медным тазом, пока идет resilver (неделю а то и больше). Понятно желание сэкономить на дисках c raid-z/z1/z2/z3, но если это системы по 200-400-600 терабайт, то такая экономия может стоить потерией всех данных в ZFS. В случае же с зеркалами, resilver делается только между двумя хардами (быстро) и не нагибает производительность в отличии от Z где для того чтобы востановить массив, надо перелопатить весь array.Почитайте, вот первое что нашлось в подверждение:
https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs.../
https://www.ixsystems.com/community/threads/some-differences.../
>[оверквотинг удален]
> процесс востановления (resilver) занимает массу времени, то весь массив может накрыться
> медным тазом, пока идет resilver (неделю а то и больше). Понятно
> желание сэкономить на дисках c raid-z/z1/z2/z3, но если это системы по
> 200-400-600 терабайт, то такая экономия может стоить потерией всех данных в
> ZFS. В случае же с зеркалами, resilver делается только между двумя
> хардами (быстро) и не нагибает производительность в отличии от Z где
> для того чтобы востановить массив, надо перелопатить весь array.
> Почитайте, вот первое что нашлось в подверждение:
> https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs.../
> https://www.ixsystems.com/community/threads/some-differences.../Вопрос был в контексте домашнего использования, если что.
> Вопрос был в контексте домашнего использования, если что.тебе чьих данных больше жалко - домашних или дядиных?
И у кого, кстати, больше денег на бэкапы и лишние диски?
>> Вопрос был в контексте домашнего использования, если что.
> тебе чьих данных больше жалко - домашних или дядиных?
> И у кого, кстати, больше денег на бэкапы и лишние диски?В обоих случаях, бекапы нужны. Но речь шла не про бекапы.
дома на бэкапы нетбабланах (иначе зачем бы мне zfs ? это и есть бэкап примерно всего)там где есть 400T - бэкап в теории есть, на практике если накроется ВСЕ - при банкротстве контора потеряет меньше, чем при попытке восстановить.
Потому что пока такой объем восстанавливается - там судебных и прочих исков и пень успеет набежать в разы больше.Если накроется кусок (и не просто так промышленная хранилка ограничивает отдельный dataset в ~14T) - то, конечно, как нибудь переживут.
> дома на бэкапы нетбабланах (иначе зачем бы мне zfs ? это и
> есть бэкап примерно всего)Нищебродство какое-то. snapshot это не бекап. Три накопителя разных производителей с одинаковыми параметрами и размерность в N TiB. Два в zfs pool mirror, один в отдельный пул backup. И send.
> там где есть 400T - бэкап в теории есть, на практике если
> накроется ВСЕ - при банкротстве контора потеряет меньше, чем при попытке
> восстановить.
> Потому что пока такой объем восстанавливается - там судебных и прочих исков
> и пень успеет набежать в разы больше.
> Если накроется кусок (и не просто так промышленная хранилка ограничивает отдельный dataset
> в ~14T) - то, конечно, как нибудь переживут.С интырпрайзом отдельная боль с бекапами. Но тоже лечится при разумном подходе. И 400T не предел.
> Нищебродство какое-то. snapshot это не бекап. Три накопителя разных производителей с одинаковыми
> параметрами и размерность в N TiB.поздравляю, вы купили 1/3 дискового пространства за 3x денег. Или 4x, поскольку разные производители могут неожиданно стоить разно.
А зачем теперь, кстати, zfs ? Форматируете в ext4/ntfs/вообще exfat и живете счастливо. Пользы от нее вам в озвученной схеме вообще никакой. Или у вас домашний компьютер на freebsd (соболезную, там выбора почти нет)?красиво жить, конечно, не запретишь, но лично у меня смысл zfs в независимости от подвернувшихся под руку дисков и того из какого трэша собрана хранилка - она должна просто работать, не требуя времени на переконфигурации и переливания данных туда-сюда. За это я готов заплатить потерей производительности (она имеет место быть) и некоторой потерей надежности. Но не тем п-цом который навязывают дорогие друзья с Украины и iX. Насчет ZoL - пока присматриваюсь, посмотрим, сколько проживет экспериментальный сервер на работе, но мнение скорее отрицательное - оно если и работает, то больше по недоразумению. И этот сервер стабильно медленнее аналогичного с btrfs.
> С интырпрайзом отдельная боль с бекапами. Но тоже лечится при разумном подходе. И 400T не предел.
да нет никакой боли, просто есть понимание, что бэкап не для решения ситуации "хранилка внезапно сгорела вся кху-ям, восстановлению не подлежит". Он для ситуации "косорукий коллега окошком ошибся и снес том, двести раз нажав Ok, один раз набрав "YES I C0NfIR/\/\ THIS!". В наихудшем случае это 14T еще актуальных данных. Плохо, но не катастрофа, за пол-дня с лент восстановится самое остро необходимое, клиентам принесут искренние извинения.
И вот обратите внимание - 14T - это предел для коммерческого решения за миллион денег. (то есть в переносе на zfs - это размер zpool был бы) Вот как-то не хотели они манипулировать кусками стораджа большего объема как одним целым.
zfs для компрессии и удобства управления всей ёмкостью. И можно при необходимости преобразовать в raidzNЧто до ZoL на серверах:
https://paste.ubuntu.com/p/kDVqnfPr6y/
https://paste.ubuntu.com/p/Dq3jy3c23j/Бекапы - они для всех случаев. Бекапить большЫе объёмы вполне себе боль само по себе.
И есть хуже ситуации, например когда программист ошибся изменил миграцию, протестил и накатил, её после месяца тестов, а в результате дропнулась колонка в колоночном хранилище.
И ленты в таких случаях вообще не применимы (да и вообще их давно можно списать). Лучше собрать пару-тройку хранилищ типа Ceph/Lustre и обозначить основное и резервные. Но всё это зависит от потребностей и возможностей.
> zfs для компрессии и удобства управления всей ёмкостьюкакое ж у вас удобство и управление, если аж три диска и из тех один в рейде, другой бэкап?
ну и что вы там такое копрессируете-компрессируете - тоже не знаю. Вот что в коде arc compress есть дидлок - знаю на собственном опыте. Наступить сложно, но некоторым удается.
# uptime
18:49:58 up 399 days, 17:58, 1 user, load average: 8,16, 9,20, 9,58
прекрасный ненужносервер, больше года без апдейтов (это ведь не только ядро, но и библиотеки). пингом валится, поди?кстати, где тут удобство, если он нарезан на какие-то автогенеренные куски, не имеющие ни малейшего смысла и даже незапоминаемые?
> И ленты в таких случаях вообще не применимы (да и вообще их давно можно списать).
голубчик, вы это рассказываете тому кто применяет и применять будет. Но по назначению, а не в виде универсальной пилюли. Ее нет. А ваша люстра вне гугля (который как раз может позволить себе потерять хоть вообще все данные - хомячки новых понапостят, его цель была хранить совершенно нечеловеческие объемы, а не надежность такого хранения в целом), стесняюсь спросить, где еще жива?
> А ваша люстра вне гугля [...], стесняюсь спросить, где еще жива?Ну мы по hpc-кластерам применяли (как и ленты, хе-хе). А гуглю-то она зачем? Первый раз в таком контексте упоминание вижу.
>> А ваша люстра вне гугля [...], стесняюсь спросить, где еще жива?
> Ну мы по hpc-кластерам применяли (как и ленты, хе-хе). А гуглю-то
> она зачем? Первый раз в таком контексте упоминание вижу.Ну вообще оно у них на облаках для hpc применимо, рассказывают:
https://cloud.google.com/blog/products/storage-data-transfer...
>> zfs для компрессии и удобства управления всей ёмкостью
> какое ж у вас удобство и управление, если аж три диска и
> из тех один в рейде, другой бэкап?Удобство в управлении всей ёмкостью и компрессия, назначение mountpoint'ов, возможность пинать снапшоты при экспериментах. После возни с lvm - ну очень удобно.
> ну и что вы там такое копрессируете-компрессируете - тоже не знаю. Вот
> что в коде arc compress есть дидлок - знаю на собственном
> опыте. Наступить сложно, но некоторым удается.Да где их нет. Софта без ошибок, даже у NASA не густо.
> # uptime
> 18:49:58 up 399 days, 17:58, 1 user, load average:
> 8,16, 9,20, 9,58
> прекрасный ненужносервер, больше года без апдейтов (это ведь не только ядро, но
> и библиотеки). пингом валится, поди?Не, не валится, и апгрейдится кстати, и не пингуется. Но прод он такой - живёт в соответствии с требованиями бизнеса.
> кстати, где тут удобство, если он нарезан на какие-то автогенеренные куски, не
> имеющие ни малейшего смысла и даже незапоминаемые?Нарезан как надо и со смыслом, а запоминать их не надо, их надо легко идентифицировать при необходимости, удобство в том как это управляется.
>> И ленты в таких случаях вообще не применимы (да и вообще их давно можно списать).
> голубчик, вы это рассказываете тому кто применяет и применять будет. Но по
> назначению, а не в виде универсальной пилюли. Ее нет. А ваша
> люстра вне гугля (который как раз может позволить себе потерять хоть
> вообще все данные - хомячки новых понапостят, его цель была хранить
> совершенно нечеловеческие объемы, а не надежность такого хранения в целом), стесняюсь
> спросить, где еще жива?Я вам не голубчик. А ленты не нужны, устарело окончательно.
У этого подхода тоже есть недостатки - под резервирование отдается аж половина общего объема дисков, и с надежностью тоже не все так радужно.
Zpool превращается в тыкву если хотя бы один vdev в нем умирает. Zpool, состоящий из нескольких mirror vdev умрет если хотя бы в одном из зеркал сдохнут сразу два диска (подразумевая, что зеркала составляются из пар дисков). Zpool, состоящий из raidz2 vdev'ов же переживет потерю двух любых дисков в любом из vdev. А raidz3 - потерю трёх.
> Zpool, состоящий из raidz2 vdev'ов же переживет потерю
> двух любых дисков в любом из vdev. А raidz3 - потерю
> трёх.Вы читали линки в моем первом посте?
> В случае помирания одного из дисков resilver занимает очень много времени и нагинает
> производительность по черному.в случае отказа диска в vdev - времени уйдет ровно столько, сколько надо чтобы прочитать весь vdev. Поскольку его таки надо весь прочитать - что с зеркалом, что с raidz
Если вы сравниваете raidz на четырех дисках с двумя 2-way mirror - да, при отказе одного диска первому придется прочитать втрое больше данных, а при отказе двух разом - в тыкву превращаются и тот, и другой (для меня до сих пор остается загадкой отсутствие средств восстановления сохранившейся информации с таких пулов). Только во втором случае у вас этого "втрое" просто НЕТ.
А если вместо 4x raidz вы соберете 3x 2x mirror для получения того же объема - тут уже и дятлу становится немножко ссыкотно.> Понятно желание сэкономить на дисках c raid-z/z1/z2/z3, но если это системы по 200-400-600
> терабайтто, вероятнее всего, их собрали неправильно, и нужно было прочитать рекомендации, сколько именно дисков допустимо собирать в raidzN (и еще следует понимать, что потери производительности никто не отменял и N>2 имеют исключительно архивную ценность) и подумать, как с этим жить дальше. Выводы будут довольно скучные и очевидные - единый пул такого размера - обречен.
А теперь прикиньте, вот есть у вас система аж на 400T, собранная, допустим, из 3T дисков в raidz2 (как и положено, по 6 в vdev) - ~35 штук, 210 дисков не считая spare (ничего такого особенного). Сколька-сколька займет переделка их в 3way mirror, и хватит ли у вас на это места в стойках и электричества, даже если деньги - нивапрос?
Меня raid-z2 неоднократно выручал. Так из массива постепенно ушли все сигейты.
> то велика вероятность, что в случае падения одного диска
> за ним последуют другиеkeywords: double fault
Интересно, насколько беспроблемным будет апгрейд с 0.7 до 0.8? с 0.6 до 0.7 проходило гладко, что не могло не порадовать.
Есть у редхата vdo, не вижу смысла в многослойном костылк. Для ядер 5.1 регрессии в виде отсутствии FPU/SIMD.
С VDO - это какойөто закат Солнца вручную с педально-шаговым управлением. Нужно периодически "подтягивать" размер сжатого устройства и файловую систему с учётом реального свободного места на физическом устройстве.
А ручной запуск ребалансинга btrfs с той же целью — это не педально-шаговый?Зато в подходе от Red Hat примерно понятно где что сломалось, поскольку технологии независимы.
btrfs мне вообще не вариант. Реальной рабочей альтернативы ZoL (чексуммы, сжатие, raid-z2; дедупликация для меня малоюзабельна из-за скорости) я лично для себя не вижу.
то есть вот этот вот редхатопц с девмапером поверх девмапера погоняющего девмапером - это не многослойный костылик, где в одном месте сжатие, в другом отдельном снапшоты, в третьем тома xfs отдельно, и попробуй угадай где и в каком слое этажерки у нас сейчас кончится место и какой утилитой это надо проверять - совсем-совсем не костылик?И невозможность банально включить сжатие на существующей fs, вообще ничего больше в ней не трогая - это, понятно, большой плюс редгадоидов, ага.
ну и отдельно очень интересно знать, какова надежность такого бутерброда - а то, знаете ли, про devmapper-то по сей день ходят слухи, что умеет внезапно обернуться тыковкой, и, в отличие от btr/zfs - там средств анализа, не то что восстановления, нет в помине.
Эти слухи ходят исключительно у вас в голове.
гы-гы - не прошло и дня - https://www.opennet.dev/opennews/art.shtml?num=50747 - и да, это исключительно "качество dm" (в dm через dm).но больным фанатикам это пофиг - они видят проблему где угодно, только не в ее источнике. (впрочем, вряд ли их квалификация позволяет понять, что написано в патче)
И это, на самом деле, и есть главный повод стоять от их фетиша подальше.
> Добавлена встроенная поддержка шифрования хранимых данных на уровне файловой системы и разделов.
> Добавлена команда "zpool trim", позволяющая информировать используемые в пуле накопители о секторах, которые больше не используются.Я все таки перееду с FreeNAS на что-нибудь линуксовое. Ура!
да, переезжай - во фринасе после мержа ловить будет нечего уже совсем.
Сейчас все NAS линуксовые, уже давно идут с btrfs, никаких проблем. Переезжайте спокойно. До тех пор, пока это рейд с избыточностью, скажем, 10. 0 это практически суицид независимо от ФС.
Не вариант, у меня RAID-Z1 (RAID5), который в btrfs все никак не заработает без поломки фс. Минимальная избыточность и максимальная плотность данных. Да, он может полететь во время ресильвера, но простои мой домашний сервак не особо пугают, и бекапы у меня есть. Логично было бы докинуть еще один диск до оптимальной конфигурации, но у меня просто физически закончилось место в корпусе, увы.
> Да, он может полететь во время ресильвера, но простои мой домашний сервак не особо пугают, и
> бекапы у меня есть.ну так может и совсем нафиг этот raid, многодисковые конфигурации btrfs нормально, вроде, поддерживает?
OpenMediaVault так-то давно уже есть. Не помню, как там у них с ZFS, не было нужды. Но с учётом, что под капотом - обычный Дебиан, прикрутить вероятно можно.
отдельным модулем, вроде работает. Но зачем?
(в смысле - зачем вообще нужна эта дебиан-бэйзед подделка? У нас есть proxmox если хочется дебиана и пока еще есть freenas с более живой версией zfs)
Праздник несколько омрачают нюансы: https://github.com/zfsonlinux/zfs/issues/8793
в чем проблема - кроме мечт обмазаться наисвежайшим?
Либо живете на ядре, которое просто работает, либо наслаждаетесь решениями больных столманизмом и рукоплещете, а вражеский zfs вообще не должен вас касаться.
Бывают случаи, когда не приходится выбирать и есть только ядро 5.x, но нужен и ZFS.
Хотелось бы при этом иметь и SIMD в ZFS.
ну странный это случай - либо ты архитектор, и ты выбираешь правильные с твоей точки зрения версии и методы работы, либо тебя не спрашивают - тогда и ты не отвечаешь за результат. Тормозит? Значит так и было задумано.Откатить вредную правку в ядре - дело пары минут, два ненужно-static выкинуть и EXPORT вернуть. Найти что там попатчили в zfs для совместимости - ну чуть подольше займет.
Но смысла так убиваться я не вижу.
Вон сегодня коллеги с телефонии пришли - ведро не видит сетевуху. Заглядываю в config - охреневаю:
CONFIG_NET_VENDOR_3COM=n и CONFIG_VIA_RHINE not set.
Привет от redhat, объявлены немодными и немолодежными. Первое это даже не сборка, это вообще ядро не задает вопросов про эти драйверы. Да, можно было включить им elrepo и таки поставить. Но: это решение redhat. Как видим, неслучайное, а вообще возможность сборки отключена. Коллеги в этом не алле, они астер на ней настраивают. Завтра запросто ibmhat поломает совсем. Поэтому - правильно, "идите и купите на базаре e1000 - еще на десять лет вам хватит, еще e100 не выпилили(таки не), цена ей копейки, а сэкономленный геморрой - бесценен".
> ну странный это случай - либо ты архитектор, и ты выбираешь...Я, конечно, могу выбрать. "Обмазываться наисвежайшим" цели не было и нет.
Но это мне будет стоить времени намного большего, чем фикс (точнее откат) превнесенной проблемы.
ну а тогда - зачем оно? То есть вот каких именно фич очень надо от 5.чтотамунас-1? которых нет в каком-нибудь 4.15, которое, пока, миновала чаша сея?
они бы еще ipv4 выпилили. и пришлось бы ipv6 прикостыливать
> Праздник несколько омрачают нюансы: https://github.com/zfsonlinux/zfs/issues/8793https://wiki.gentoo.org/wiki/ZFS#Installing_into_the_kernel_...
Интересно, как в Ubuntu, где ZFS из коробки.
в каком месте ваша корявая инструкция решает проблему "лап4атые запретили сторонним модулям использовать FPU, чтобы выдать свое неумение писать быстрый код за чужие тормоза" ?оно, понятно, исправляется двустрочным патчем в ядре и откатом пятнадцатистрочного в zol, но нафига?
> чтобы выдать свое неумение писать быстрый код за чужие тормоза" ?Странная мысль. Расшифруйте.
> оно, понятно, исправляется двустрочным патчем в ядре и откатом пятнадцатистрочного в zol, но нафига?
Что нафига?
Очевидно, что технически проблема возникла на пустом месте, точнее из идеологических/юридических соображений.
Очевидно, что в полезной, но не GPL-ной ZFS не хочется терять в производительности на ровном месте.
> Странная мысль. Расшифруйте.это диверсия. Намеренная. Чего тут не понимать?
> Очевидно, что технически проблема возникла на пустом месте
это не проблема. Это сознательное вредительство. Использовать fpu и раньше было нельзя, "официальные" функции изначально объявлены gpl-only. Единственное назначение подобных объявлений - чтобы не-gpl код работал плохо. Потому что победить честно они не могут. zfs использовала случайно торчащие наружу аналоги с __ в имени, которые уже по названию очевидно что не предназначались для использования в обход штатных оберток, и торчали наружу по недосмотру. Недосмотр зачищен.
> Очевидно, что в полезной, но не GPL-ной ZFS не хочется терять в производительности на ровном
> месте.это НЕ ровное место. Это позиция персоны, приближенной к самому императору, подкармливаемой объедками со стола IBM и Oracle. Которые совершенно не намерены позволять развиваться каким-то альтернативам своих уродливых поделок.
судьба zol теперь совершенно предсказуема, и отправится она туда же, куда devfs.
не думаю что им поможет выигранный vmware по совершенно аналогичному случаю судебный процесс - у них столько денег нет.
По сути я с тобой согласен.
Просто в твоем мессадже много экспрессии.
Ну и исходный твой мессадж был несколько туманен.
Это как-бы и так понятно, учитывая развитие альтернативы в виде btrfs.
Если-бы код zfs был под GPL, а не CDDL, вряд-ли бы кто-то возражал против его включения в ядро, и btrfs вряд-ли появился-бы.
А так Torvalds и Сo имеют право делать свой код ориентированным на совместимость с GPL-only.
Как только btrfs допилят до сопоставимой с zfs кондиции, в существовании ZoL не останется смысла.
> Если-бы код zfs был под GPL, а не CDDLгуглите историю devfs. Вполне себе была под gpl, что не помешало саботировать ее принятие до момента, когда автор попал в рай - под совершенно высосанными из пальца предлогами.
ну или можете посмотреть на текущее состояние вайргада (там, правда, долбанутость автора примерно равна, поэтому я тут ни за жабу, ни за гадюку не болею, просто наслаждаюсь зрелищем).
> А так Torvalds и Сo имеют право делать свой код ориентированным на совместимость с GPL-only.
а мы имеем право считать их плохими п-сами, намеренно начавшими мешать делать чужой код, потому что неспособны написать свой эквивалентного качества, и плюющими на своих пользователей (все правильно, пользователи последние двадцать лет не нужны, линукс давно уже не community-проект, жрет с лопаты что ебеме приносит).
по этой же причине "до сопоставимой кондиции" btrfs не допилят примерно никогда. Потому что незачем, "и так сойдет", а ебеме он не нужен - будете пользоваться редхатовским бутербродом и благодарно кланяться.
А zfs от нас в ближайшее время никуда не денется, даже если орацлу надоест - старые выпуски в тыкву-то вряд ли превратятся.
Я не настолько пессимистичен.
История развития linux конечно полна разными событиями, но в ней точно нет подтверждения этому утверждению "намеренно начавшими мешать делать чужой код, потому что неспособны написать свой эквивалентного качества".
GPL и создан для того, что-бы не позволять скрывать код, а значит в том числе демонстрировать его качество и давать возможность заинтересованным улучшать его качество.
А всё остальное, про подлости, "ебеме" и т.п. - это лишь злословие.И btrfs точно допилят, слишком много заинтересованных в нём.
> в каком месте вашаО как, я уже разработчик Gentoo.))
> корявая инструкция решает проблему "лап4атые запретили сторонним модулям
> использовать FPU, чтобы выдать свое неумение писать быстрый код за чужие
> тормоза" ?Это милейший, не моя проблема. Но ежели кто с ней столкнулся, решить её ничего не стоит. Упс, я хотел сказать, мне на её решение потребуется неделя-другая ковыряния в носу с умным видом и пития кофэ. Ты ведь не выдашь этот маленький секрет? Пиши-пиши в том же духе.)))
> Это милейший, не моя проблема.тогда зачем вы лезете в обсуждения не своей проблемы с не имеющей к ней ни малейшего отношения инструкцией о выпрямлении некоторых череззадничных проблем генты?
> Но ежели кто с ней столкнулся, решить её ничего не стоит.
но вы-то ниасилили, как я погляжу.
> Упс, я хотел сказать, мне на её решение потребуется неделя-другая ковыряния в носу
это пока не подтверждено практикой. Может ты ее вообще ниасилишь решить, откуда нам знать. Судя по инструкции не от того места - вполне вероятно и такое.
А тем кто могут - оно, судя по треду, по большей части неинтересно - болезнь неизлечима, поддерживать больного можно, но эвтаназия дешевле и практичнее.
>> Это милейший, не моя проблема.
> тогда зачем вы лезете в обсуждения не своей проблемы с не имеющей
> к ней ни малейшего отношения инструкцией о выпрямлении некоторых череззадничных проблем
> генты?Что бы ссылаться на твоё экспертное мнение, когда мне не поверят, что менее чем за месяц задачу не решить.
>> Но ежели кто с ней столкнулся, решить её ничего не стоит.
> но вы-то ниасилили, как я погляжу.эТы внимательнее гляди. Монитор то твой.
>> Упс, я хотел сказать, мне на её решение потребуется неделя-другая ковыряния в носу
> это пока не подтверждено практикой. Может ты ее вообще ниасилишь решить, откуда
> нам знать. Судя по инструкции не от того места - вполне
> вероятно и такое.Уговорил, месяц. Или иди ищи себе какого-нибудь идиота. ;-)
> А тем кто могут - оно, судя по треду, по большей части
> неинтересно - болезнь неизлечима, поддерживать больного можно, но эвтаназия дешевле и
> практичнее.А ты уверен, что на тебе корона, а не шапочка из фольги?
Ну, разве что оттуда интересное словосочетание выдернуто "GPL condom". Экая конструкция. А так да, решат со временем. Это ж только на свежих ядрах.
> Ну, разве что оттуда интересное словосочетание выдернуто "GPL condom". Экая конструкция.на vmware за такую конструкцию подали в суд. Правда, позорно прос...ли.
да, я тоже думаю что со временем столманодолбанутые на грантах ibmhat их порешат окончательно.
Кому нужна zfs, работающая нормально "только на ядре 2.6.32"?
> да, я тоже думаю что со временем столманодолбанутые на грантах ibmhat их
> порешат окончательно.ВМФ исключительных против Минэнерго? Одобряем. =)