Комментарии 80
Чётка FS, но с ZVOL проблемы (под Linux) и давно...
А какие с Zvol проблемы, напишите плиз? Интересно.
Тоже интересно, потому как ни на виртуалках через qemu/kvm, ни с lio, ни даже с кроссдедупликацией экспортированного через lio ntfs-тома и обычного zfs dataset никаких проблем, не говоря уже про проблемы-проблемы, выявлено не было.
А есть информация о проблемах? Будем рады тикетам https://github.com/openzfs/zfs/issues !
ZVOL от dataset некоторое время отличался производительностью на большом количестве потоков, но в релиз v2.2 вошло не малое количество патчей как раз об улучшении его перформанса. Известных багов не помню.
Была какая то бага что приводила к дедлоку если сделать swap на ZFS. Не знаете починили или все еще кейс?
По вашей ссылке есть тикет, куда стоит прикреплять проблемы со SWAP https://github.com/openzfs/zfs/issues/7734 , пока рекомендация не изменилась, дедлоки всё ещё возможны.
https://github.com/openzfs/zfs/issues/9172 - и эта проблема и похожие - закрыты автоматически за неактивностью, а не по исправлению. Это как сказал один из пользователей github:
it's like sweeping dirt under the carpet (https://github.com/openzfs/zfs/issues/9693#issuecomment-882027592)
Насчёт производительности, если вот эти проблемы решены:
https://github.com/openzfs/zfs/issues/14346
https://coda.io/@ff0/zvol-performance-issues
https://github.com/openzfs/zfs/issues/11933
, то гуд, если нет, то ждёмс...
https://github.com/openzfs/zfs/issues/14346 речь вроде не о ZVOL, плюс там явно указано про проблему с SMR дисками, что относително ожидаемо
https://github.com/openzfs/zfs/issues/11933 тут в конце накидано ссылок на патчи по теме, автор тикета не отписался об их проверке
Есть ещё интересные фокусы с zvol, видел как iostat кажет на группе nvme накопителей загрузку около 1%, а на /dev/zd0 (raidz на эти самые nvme накопители, сам volume выставлен FC target'ом на другой хост) - 100% и скорость записи втрое ниже чем на Solaris с HDD (ZStorage). Но насколько актуальны эти фокусы, относительно версии драйвера и ядра linux, не уточню - не я производил сетап хоста и не я эксплуатирую.
Ещё не читал, но начало очень интересно е. Спасибо, автор!
Уже прочитал.
Спасибо! Очень интересная статья про zfs. Использую её для себя и тестя на наших nas и пк-шках.
Выбираю её из-за контроля четности - хочу быть уверен, что мои данные не испортятся от "тихой порчи".
Ну и остальные плюшки клёвые, хотя мне не очень нужны в моём частном случае.
На свою винду- рабочую станцию ставлю трунас на хайпер ви и в хосте использую через самбу, nfs, iscsi на прокинутых в виртуалку физических дисках.
То есть на NTFS у меня только виндовс, а всё остальное на виртуальных девайсах от zfs.
Я очень доволен.
Но самая большая беда — это отказ. В случае отказа этой железки, а железо когда-то всё равно сдохнет, вам придётся не просто найти аналог, а найти именно ТУ САМУЮ железку с ТОЙ САМОЙ прошивкой. У другой железки будет другая логика построения RAID, и у вас просто не сойдется массив, так как железка не будет знать, как его собрать.
Это мягко говоря неправда, например, вся линейка LSI вперед совместима нормально, Adaptec тоже. Я даже заводил R1 на Adaptec от LSI (Broadcom), хотя это галиматья. Просто держите в зип относительно новый Broadcom и будет вам счастье. Само собой куча всякого экзотического железа типа Nytro или Areca.
Проблемы несколько иные: факт, что массивы на hw raid требуют очень надежных и именно серверных дисков и тем не менее разваливаются куда чаще. А, например, RAID HPE может не принять в рейд диск другой серии или большего размера легко.
У zfs плюсов много, но, например, я никогда не поставлю zfs вместо mdamd + lvm + ext4 для томов VM, ну просто потому, что это нафиг не надо.
Спасибо за фидбек! Формулировку поправил.
> но, например, я никогда не поставлю zfs вместо mdamd + lvm + ext4 для томов VM, ну просто потому, что это нафиг не надо.
удачи с ИНКРЕМЕНТНЫМИ снепшотами на lvm :)
И зачем бы мне они были нужны, если, к примеру, kvm/libvirt/qemu это умеет на уровне qcow2?
Удачи с оптимизацией оверхеда в lxc-over-qemu
А зачем мне lxc over qemu, если, внезапно, есть KVM, если нужны виртуалки, или Docker/k8s ну или тот же lxc без qemu, если контейнеры?
Аргументы про оверхед виртуалок в треде про zfs - это нечто странное. На zfs вообще недоступна производительность по iops, которая может быть получена с использованием mdam+lvm+ext4.
если, внезапно, есть KVM
ВНЕЗАПНО, qemu и использует kvm
lxc без qemu, если контейнеры?
И как там с инкрементными снепшотами?
На zfs вообще недоступна производительность по iops, которая может быть получена с использованием mdam+lvm+ext4
sync=disabled, только при этом не нужно отказываться от снепшотов.
Ну и пирог из mdam+lvm+ext4 — это не про скорость.
Это же Вы пишете про lxc+qemu? Есть где-то, что я писал, что qemu kvm не использует?
А почему Вы так на инкрементных снэпшотах зациклились? Я каждую ночь бэкаплю по 30tb томов через 20gbit/s с 10 хостов со снэпшота lvm2 по nfs на zfs R6 и все у меня хорошо.
Sync=disabled - это вы ловко придумали :) есть у меня такой конфиг на бэкап сервере из предыдущего пункта, где потерять данные не сильно жалко при аварии, не думаю что такой конфиг разумен на сервере, где тома виртуалок…
Чем не угодил mdadm+lvm+ext4? У меня на пачке u2 nvme R1+lvm+ext4 все работает - всем машинам со стандартной политикой write through с самыми разными планами хватает. Что я делаю не так?
Возможно, мой подход и кондовый, но я знаю что бандл на хосте не начнет козлить и он простой как три копейки и траблшутинг не нужен, а я хочу чтобы среднестатистический сисадмин мог восстановить инфраструктуру в случае чего, а не смотреть на десятки параметров zfs в поиске того, где же что подкрутить, чтобы оно не козлило.
А почему Вы так на инкрементных снэпшотах зациклились?
Потому что вас об этом спросили, а вы стараетесь сделать вид, что это вовсе не вы.
Вот, смотрите:
Это же Вы пишете про lxc+qemu?
Это чье сообщение? Ваше. Вы предложили qcow2 как замену снепшотам. Значит все, что требуется покрыть снепшотами (включая корень хоста, ха-ха), должно быть размещено на qcow2.
В этом смысл и суть вашей дури, от которой вы теперь яростно открещиваетесь, пытаясь сказать сам дурак.
И вам даже кажется, судя по всему, что
это вы ловко придумали :)
В txg все равно данные попадут по ближайшему fsync, а репликация все равно возьмет еще более крупные куски, с интервалом в пару минут. Так что вообще без разницы.
Чем не угодил mdadm+lvm+ext4?
А вы помните, в каком контексте вы привели эту связку как аргумент? В контексте производительности.
Что случается с производительностью тонкого lvm-тома после снятия с него первого снепшота? Она падает.
Это не говоря уже о том, что mdadm в ней — не нужен много лет как.
И о том, что extN по производительности — середнячок даже среди журналируемых систем.
И о том, что настоящая производительность™ достигается после отказа от гарантий сохранности данных, все остальное — компромиссы.
Возможно, мой подход и кондовый
По части возможностей lvm так точно. Отчего в схеме появляются лишние слои, растет сложность как диагностики так и управления.
а не смотреть на десятки параметров zfs в поиске того, где же что подкрутить, чтобы оно не козлило
Смотреть в сотни параметров mdadm, devmapper, pv*, vg*, lv*, самой фс, наконец, дающих на выходе сотни миллионов сочетаний — по вашему проще, чем в полста отлично документированных параметров zfs? )))
Все ясно, после отказа от гарантий сохранности данных нет смысла дальше что-то обсуждать. Но так, для интереса, посмотрите к чему было мое сообщение, на которое Вы ссылаетесь.
Знаете, этот вам даже немного завидует… у вас впереди столько чудных открытий, например, шкала производительность⇔надежность, на которой увеличение производительности обязательно надежность снижает; или тот факт, что не-CoW/LogStructured FS в принципе не могут гарантировать сохранности пользовательских данных…
посмотрите к чему было мое сообщение
К тому, что вы очень выборочно и удобно потеряли половину промежуточных звеньев, перемешали остаток и заполнили лакуны как вам хочется? )
Что используется в качестве загрузчика у вас на ноутбуке?
У меня было на примете 3 варианта:
1) Ядро и initramfs лежат на ESP, что ужасно, т.к. fat32.
2) ZFSBootMenu, который так же лежит в ESP на fat32, но уже ядро может лежать на ZFS. Меня смущает тут kexec, т.к. могут быть проблемы с оборудованием.
3) EFI драйвера https://efi.akeo.ie/. К сожалению я так и не смог с помощью них увидеть ZFS в efi shell. Но на мой взгляд это лучший вариант. На ESP будет лежать только драйвер.
Я использую консервативный grub2 и ESP , примерно аналогичный гайду https://openzfs.github.io/openzfs-docs/Getting Started/Debian/Debian Bookworm Root on ZFS.html . Grub имеет ограниченный readonly zfs драйвер, который вычитывает ядро с отдельного BOOT пула (чтобы уменьшить на нём количество активных feature flags).
Да вроде №1 не так уж и страшен:
❯ ls -l /boot/esp/EFI/Linux
total 65M
-rwxr-xr-x 1 root root 32M июл 28 12:13 6.4.8.zen1-1-linux-zen_BACK.efi
-rwxr-xr-x 1 root root 33M сен 27 16:11 6.5.9.zen2-1-linux-zen.efiСкрипты mkinitcpio сохраняют одно предыдущее ядро, размер uki небольшой — даже в дефолтные виндовые 100МБ влезет.
Проверку целостности файла можно возложить на secureboot (или дублировать на зеркало).
1) Ядро и initramfs лежат на ESP, что ужасно, т.к. fat32.
Чем ужасно-то?
Я сам очень люблю ZFS, но мне кажется, что странных утверждений в статьях стоит избегать.
Дальше можно говорить про производительность, потому что мы не хотим, чтобы эта железка стоила как сам сервер или еще дороже. Соответственно, оборудование в ней будет стоять более дешёвое. Например, ARM.
Производительность актуальных сейчас контроллеров Broadcom и Adaptec в 99% случаев упирается не в процессор контроллера, а в PCIe или диски (если это, конечно, не несколько NVMe).
Можно компенсировать это наличием батарейки, которая позволит нам кешировать синхронную запись.
Та самая батарейка, которую мы вставляли для увеличения производительности, в случае отказа даст дикую деградацию производительности
Write back — это не «кэширование синхронной записи». Для системы RAID-контроллер презентует свои тома в виде блочных устройств. Система может писать туда синхронно, и с Write Back контроллер будет подтверждать запись блока сразу после помещения его в кэш, в отличие от Write Through (поместили в кэш, но дождались записи на диски).
Защита кэша при аварийном отключении питания уже давно не основана на продолжительном питании от литиевой батареи — вместо этого используются ионисторы, питающие модуль лишь на время, необходимое для копирования содержимого DRAM на флеш. Модули защиты с ионисторами тоже попадают в гарантию, но там AFR порядка 0,1% и связан с браком, выходом из строя других компонентов, а не с деградацией ионисторов. Первые модули (ZMCP у Adaptec, CV у LSI/Broadcom) работают уже больше 10 лет, там давно уже сами серверы морально устарели.
Прирост производительности WB дает только на медленных дисках, т.е. HDD. На томах из SSD (во всяком случае на нескольких последних поколениях Broadcom и Adaptec) будет быстрее Write Through.
найти именно ТУ САМУЮ железку с ТОЙ САМОЙ прошивкой
Не угадали. Про это уже писали.
для этого нам требуется целый набор утилит для каждого слоя
Для ZFS не нужно иметь дело со smartctl и nvme-cli?
С этим, конечно, тоже можно бороться. В классическом Unix Way, где есть слои, мы добавляем ещё один слой, который начинает делать что-то ещё.
dm_integrity надо использовать поверх накопителей, а не поверх md/LVM, иначе в нем никакого смысла нет.
Спасибо за фидбек!
Производительность актуальных сейчас контроллеров
Прирост производительности WB дает только на медленных дисках, т.е. HDD
Всё верно, вы отлично подсвечиваете нюансы. Оригинальный доклад, как и этот обзор, я целил как общий обзор среднестатистических хранилищ на не только свежем железе, и секция про железо претендует на отдельную статью. Кейс с максимально производительным аппаратным стораджем - один из возможных.
Для ZFS не нужно иметь дело со smartctl и nvme-cli?
Кстати, сейчас появилась удобная возможность использовать zpool status с флагом -с, например zpool status -c smart подмешает информацию по smart устройства. Также есть zed агент, который умеет оповещать о проблемах с носителями пула.
Вот только zed агент крашится, если минимум один из критических vdev любого zpool недоступен при импорте на старте системы. После этого zpools, даже живые, неюзабельны, там что-то ещё ломается. Это грустно, поэтому пришлось писать свой импортёр на питоне, чтобы анализировать vdev и не импортировать пулы, которые такое вызовут.
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
scan: resilvered 27.7G in 00:04:28 with 0 errors on Mon Oct 23 22:51:07 2023
config:
NAME STATE READ WRITE CKSUM health temp nvme_err ata_err realloc rep_ucor cmd_to pend_sec off_ucor
warmsands DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
nvme-INTEL_SSDPEKNU010TZ_PHKA121304MD1P0B-part2 ONLINE 0 0 0 PASSED 35 0 - - - - - -
4460342986653721468 UNAVAIL 0 0 0 was /dev/disk/by-id/usb-Realtek_RTL9210_NVME_012345678907-0:0-part2 - - - - - - - - -
errors: No known data errorsЭто просто песня )
Ну вылетело у одно плечо из зеркала, второе живо. Это нормальное поведение, такое же как в BTRFS/md/dm RAID1, в чем тут "песня"?
В использовании MDADM на текущий момент необходимости нет - соответствующие функции также реализованы в LVM (lvcreate --type mirror -m 1 ...). Оно оставлено скорей для тех, кому идеологические причины не позволяют использовать LVM.
DM-integrity также уже штатно используется в LVM (lvcreate --raidintegrity y ...)
А что про ZFS - то оно, конечно, интересный продукт - но не для случаев, когда надо "зубами выгрызать" каждый десяток микросекунд в латенси.
Многие считают, что для ZFS нужна обязательно память с ECC. Поэтому, они применяют системы с поддержкой ECC, а это процы с контроллером памяти ECC, материнки и плашки памяти специальные.
Также в некоторых чипах LPDDR4,5 появилась возможность внутреннего аппаратного контроля ECC, что избавляет от необходимости разводки дополнительных чипов памяти и применения процессоров с поддержкой ECC. Получается, что с применением таких чипов памяти как LPDDR4,5, оснастить ECC можно будет любую систему, даже ту, в которой контроллер памяти проца не поддерживает ECC.
Насколько это вообще важно чтобы система, на которой устанавливается ZFS, поддерживала аппаратный контроль ECC?
Распространение ОЗУ без ECC и является недоразумением. В ОЗУ должен быть ECC.
Причем здесь недоразумение, существуют системы с избыточностью и без. Вопрос был насколько реально нужна избыточность для ZFS. В чем выигрыш при установке ZFS на систему с избыточностью в плане кодирования?
Чем выше радиационный фон, тем выше вероятность инвертирования значений в ячейках памяти. ZFS всё протаскивает через ARC, который большой и постоянно в ОЗУ. Дальше сами считайте вероятность возникновения ошибок в данных прошедших через ОЗУ без ECC и решайте насколько важны ваши данные. У меня дома ZFS на ПК без ECC - пока не заметил искажений данных. Но это не отменяет факта: ОЗУ без ECC - недоразумение.
С любой другой файловой системой будет page cache в памяти месяцами торчать, что, как бы, то же самое.
Чел интересовался за ZFS. А так это вообще относится ко всем данным находящимся в ОЗУ.
Так в том-то и штука, что zfs тут ничем принципиально не отличается, а из подачи можно сделать вывод, что это недостаток )
По этому поводу мной был оставлен первый комментарий - https://habr.com/ru/companies/vk/articles/770300/comments/#comment_26109430. Рекурсия ;)
Встроенный ECC в DDR5 не равноценен обычному ECC - он не end2end и данные всё ещё могут побиться вне чипа памяти, по пути в процессор и т.п.
данные и на кристалле могут побиться. На мой взгляд, вероятности ошибок на плате и на кристалле одного порядка при условии, что плата разведена соответствующим образом. Так что это не панацея.
Все кеши в процессоре тоже покрыты ECC, так что полноценный ECC в RAM с 72-бит шиной между модулем и процом даёт неплохую защиту от повреждений (ну, или по крайней мере детектирует их).
Неправильно оцениваете.
Передача данных — парафазная. Линия данных — не зарядовая. Данные на линии находятся на порядки меньше, чем в памяти — на много порядков. Кроме того, они защищены битом коррекции.
Одиночная альфа-частица, неудачно пролетев через дорожку, не вызовет ничего заметного на приборах (если не породит ливень вторичных частиц, но такое событие выходит за рамки обсуждения). А вот зарядовую ячейку — пробьет, заряд утечет и вот уже битфлип.
Насколько это вообще важно чтобы система, на которой устанавливается ZFS, поддерживала аппаратный контроль ECC?
Не важнее, чем для любой другой ФС. Более того, ZFS во многих случаях сможет явно сказать о проблемах сильно раньше потери данных и пула. Я когда-то развлекался с разгоном ОЗУ, приводил данные к корраптам, после сброса настроек ОЗУ к дефолту данные просто восстановил реинсталлом пакетов, этот пул до сих пор жив и используется :)
получается, что ECC дает лишь небольшой выигрыш, но так или иначе, ничего абсолютного не произойдет, если система будет без аппаратного ECC
Произойдёт.
Данные могут побиться в процессе записи из памяти на диск и никакой ZFS от этого не спасёт - контрольные суммы будут посчитаны уже для битых данных.
Поэтому ECC как по мне - это must-have для любой системы, где важна хоть какая-то надёжности и сохранность данных. Тем более что цена сейчас на такие модули практически равна обычным, а всякие AMD десктопные поддерживают ECC.
На практике только одиночные ошибки исправляются (в большишнстве случаев), и абсолютной надежности и сохранности все равно не будет. Так что для определенных задач может ECC аппаратный не так и нужен будет, а для других более ответственных задач и существующих аппаратных способов защиты не хватит.
Было бы здорово все таки понять где та грань когда реально нужна аппаратная поддержка ECC, а когда нет. Опять же, где та грань между встроенными механизмами ECC у LPDDR и внешними схемами с дополнительной памятью.
Пока что видится, что реальных аргументов нужна ли аппаратная поддержка ECC или не нужна, так и нет. Одни слова.
Есть официальный документ: https://openzfs.github.io/openzfs-docs/Project and Community/FAQ.html#do-i-have-to-use-ecc-memory-for-zfs
Я бы на него ориентировался. Ну и опять же - как по мне экономить копейки на ECC смысла нет. Лучше с ним, чем без.
Я как мейнтейнер этой доки подсвечу продолжение оттуда: "For
home users the additional safety brought by ECC memory might not justify
the cost".
Если ECC есть - хорошо, если нет - ситуация не хуже чем для любой другой ФС. Для "enterprise environments" для любой инсталляции и ФС рекомендуется ECC.
Другими словами, для домашнего применения можно и без ECC. Думаю, что вполне разумный подход и достаточно четкое деление.
Я бы не делил на домашние и не-домашние. Просто зависит от того, ценны ли тебе твои данные или ты допускаешь что в каком-то из тысяч JPEG-ов домашней коллекции у тебя что-то побьётся (что, в принципе, не страшно).
У меня было довольно прилично случаев, когда какие-то старые фотки (10-15 лет) уже не открывались после нескольких миграций между разными хранилищами. Или имели много артефактов (видно, например, только половину). Иногда может побиться что-то важное.
Поэтому для своих NAS я выбрал ZFS+ECC и при миграции на новый делаю проверки контрольных сумм.
Во, спасибо за наводку, то что искал. Насчёт копейки тут не совсем так. Это вопрос не только железа, но и времени на проектирование и целесообразности использования существующих разработок. Особенно актуально для всякого рода мобильных систем
Ну я даже не знаю что там проектировать. Если есть возможность - ставишь ECC. Если нет - ну, значит нет.
Можно ещё вот почитать: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35162.pdf
About a third of all machines in the fleet experience at least one memory error per year (see column CE Incid. %) and the average number of correctable errors per year is over 22,000.
Так что это не редкие явления, при этом сильно зависит от оборудования судя по всему.
При переразгоне как правило комп уходит в ребут не успев ничего записать на винт, а вот автор англоязычной стать потерявший данные из-за глючной памяти, которая вспоминала часто не то и не так как записывалось, очень горько плакал над своими потерянными данными, в его случае менялись иногда отдельные биты данных и происходило это не часто, что привело к порче метаданных у его ZFS. Так что установка zfs на ноутбук это всё ещё рисковое мероприятие, хотя если это ryzen там можно включить сквозное шифрование памяти и любая ошибка приведет к тому что данные не расшифруются, что если произойдёт, то будет замечено сразу...
Меня зовут Георгий Меликов, я работаю в VK Cloud, являюсь руководителем направления IaaS разработки. Мы занимаемся не только хранилищами, но и программными сетями. Но так как у нас в проде ещё нет ZFS, то я пишу в качестве контрибьютора проекта OpenZFS.
Спасибо за статью. Есть ли у вас уже предположения, для каких нагрузок вы могли бы использовать OpenZFS в VK? Так кажется, что большинство современных БД (sql/очереди/s3) делают много аналогичных вещей - также считают чексуммы данных, пишут WAL, делают репликацию данных и тд. Выглядит так, что используя вместе с ними OpenZFS мы будем часто делать операции дважды.
Я слышал, что люди используют OpenZFS для тестовых стендов вместе с PostgreSQL, чтобы за счет COW получить за бесплатно идентичные базы данных. Есть ли какие-то еще интересные места для использования данной FS?
Если говорить про использование внутри облаков -то вот интересный кейс https://www.youtube.com/watch?v=fqQ95LlwOGg&list=PLaUVvul17xSdUK50FR3zXkGLa7hxzKIgA&index=8 https://docs.google.com/presentation/d/1fZcVvGNtG5V4JyKG7IlpzZR37YtZdI0-/edit#slide=id.p1
А если говорить про использование поверх облаков внутри виртуалок (кроме перечисленного вами) - есть много интересных кейсов, например в mailing lists openzfs видел как кто-то zfs юзает для сжатия поверх локальных дисков. Вообще ZFS под базами имеет смысл, если важнее оказывается итоговый объём, а не выжимание последних iops (такой кейс знаю у крупных игроков на российском рынке).
если бы у btrfs существовал аналог zvol я бы про zfs забыл навсегда..
в теле статьи говорится что без zfs для многотомных требуется много уровней абстракции (причём не понятно почему на пикче lvm находится под mdadm а не над ним), но сама zfs тоже предлагает "лишнюю" абстракцию ввиде zdev без которой btrfs и bcachefs обходятся но делают всё то же самое (и даже гибче, в zfs ты не можешь поменять raid10 на raidнапример6 без дополнительных дисков, а в btrfs можешь).
Очень интересная статья, спасибо!
Во-первых спасибо за труд. Во-вторых есть вопрос. Допустим, у меня есть система, к которой я подключил пять дисков для создания raidz1. Всё настроил, всё работает. Затем я решил собрать новый компьютер. Поставил систему и хочу перенести сюда те пять дисков. Имеет ли значение порядок добавления дисков? Т.е. на старой системе zfs была собрана из sdb/sdc/sdd/sde/sdf, а на новой я по ошибке ли, запамятовал ли, но собираю ту же zfs в другом порядке.
UPD: сам спросил, сам ответил: похоже, что порядок значения не имеет. zpool import -f poolname всё корректно сделает. Ещё рекомендуют задавать GPT метки дисков (например).
Интересно! Спасибо за материал
Спасибо, в основном знакомые вещи (был опыт использования ZFS в Lustre вместо MegaRAID), но все равно интересно и полезно было почитать .
И всё дошло до того, что мы из этой же кодовой базы сейчас можем собирать модуль ZFS и для FreeBSD. Таким образом мы получаем абсолютно тот же функционал уже на двух операционных системах
Правильно ли я понимаю, что можно без проблем импортировать ZFS пул из Linux в FreeBSD и наоборот?
Переизобретаем файловую систему: (Open)ZFS