https://www.opennet.me/openforum/vsluhforumID3/101997.html После десяти месяцев разработки доступен (http://list.zfsonlinux.org/pipermail/zfs-announce/2015-April/000001.html) релиз ZFSonLinux 0.6.4 (http://zfsonlinux.org/), реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Готовые установочные пакеты подготовлены (http://zfsonlinux.org/) для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Gentoo, Sabayon Linux и AltLinux.<br><br><br><br>В рамках ZFSonLinux подготовлена реализация компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre. Наработки проекта основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и https://www.opennet.me/openforum/vsluhforumID3/101997.html#104 Thu, 11 Jun 2015 12:07:12 GMT &gt; Вообще-то как видим на примере brfs - работает. <br><br>http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-and-lvm-with-kvm-a-storage-performance-comparison.html?start=5<br><br>и вывод:<br><br>http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-and-lvm-with-kvm-a-storage-performance-comparison.html?start=10<br><br>For VMs storage, stay well away from BTRFS: not only it is marked a &#8220;Tech Preview&#8221; from RedHat (read: not 100% production ready), but it is very slow when used as a VM images store.<br> https://www.opennet.me/openforum/vsluhforumID3/101997.html#103 Wed, 22 Apr 2015 11:47:20 GMT &gt; А чем экстент фундаментально отличается от блока переменного размера,<br>&gt; с очень большим максимальным размером? У zfs трабл в этом самом размере, <br>&gt; что обрекает их ворочать немало метаданных даже в случае когда можно <br>&gt; было бы просто вкатить все одним регионом, с компактным и быстрым <br>&gt; описанием. Наверное поэтому оно так и выглядит в бенчах vs btrfs. <br><br>CoW и экстенты плохо совместимы между собой.<br><br>У ZFS - более простой и надежный код в этом месте,<br>ценой некоторого уменьшения производительности.<br><br>У BTRFS - попытка сделать файловую систему и максимально фичастой<br>и максимально производительной, что ведет к усложнению алгоритмов и кода.<br>А если код сложный - в нем может быть больше нетривиальных ошибок и глюков.<br><br>Если надо "ехать" - тогда ZFS выглядит более привлекательно, <br>Если нужны "шашечки" - тогда более привлекательно выглядит BTRFS.<br><br>&gt; А можно вот как-то на уровне ФС сжульничать с чем-то типа снапшотов, <br>&gt; freeze/thaw и прочая, чтобы избавиться от постоянной записи в бэкапируемый файл. https://www.opennet.me/openforum/vsluhforumID3/101997.html#102 Wed, 22 Apr 2015 11:17:18 GMT В request для trim указан milestone 0.7.0, которая, вроде, следующая.<br> https://www.opennet.me/openforum/vsluhforumID3/101997.html#101 Wed, 22 Apr 2015 04:37:19 GMT &gt; А вот интересно: почему в каждой теме про ZFSonLinux так свирепствуют любители BTRFS?<br><br>Наверное потому что<br>1) В любую новость с btrfs прутся ZFSники.<br>2) Саночные сектанты уже достали своим маркетинговым булшитом, скидками и подтасовками.<br><br> https://www.opennet.me/openforum/vsluhforumID3/101997.html#100 Wed, 22 Apr 2015 04:34:56 GMT &gt; Очень репрезентативная выборка, однако :) <br><br>Вы так говорите, как будто в ZFS багов нет :)<br><br> https://www.opennet.me/openforum/vsluhforumID3/101997.html#99 Wed, 22 Apr 2015 03:15:07 GMT &gt; Из-за того, что в файловую систему добавили новую сущность <br>&gt; - ее код от этого проще не становится, а только лишь наоборот. <br><br>Не "новую". А лишь "сделали по другому". Сущность "аллокатор" есть в ФС по любому. А то что он будет экстенты делать вместо колупания блоков и будет заканчивать свою работу в большинстве случаев быстрее - так поэтому у всех новых ФС аллокаторы и делают на основе экстентов. Блочные аллокаторы - архаика, новые дизайны все как один на экстентах.<br><br>&gt; Разница только в том, сколько места на диске и в памяти будет занимать такой блок.<br><br>С блоками именно жестко фиксированного размера возможен ряд упрощений математики и оптимизаций, типа какого-нибудь быстрого и лобового вычисления смещений без смотрения на кучу других вещей по типу "а какого размера был блок?". А с блоками переменного размера такой номер уже не прокатит. В результате у саней получилась какая-то буита "ни два ни полтора". Оно одновременно и достаточно сложное и параметрами не блещет, так что от бенчмарков btrfs ZFS сцaли https://www.opennet.me/openforum/vsluhforumID3/101997.html#98 Wed, 22 Apr 2015 01:57:21 GMT &gt;&gt; но может быть через какое-то время BTRFS и станет стабильной файловой системой.<br>&gt; Не скажу за RAID5/6, а остальное вполне работает уже сейчас.<br><br>Работает, но пока что на уровне Technology Preview, не для production:<br>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-btrfs.html<br><br>Даже Docker, который вроде бы считается уже стабильным - в Red Hat<br>не рекомендуют для использования в mission critical сервисах.<br>И как оказалось - совсем не зря, сравнительно недавно <br>там было найдено большое количество уязвимостей и глюков.<br><br>&gt;&gt; В OpenZFS не смотря на ее почтенный возраст до сих пор полно проблем и глюков: <br>&gt; Внезапно, в любой достаточно большой программе есть достаточное количество багов.<br><br>То есть, по качеству кода Linux == Windows, или как это утверждение надо понимать?<br><br>&gt; И никакой маркетинговый булшит от санок не может это изменить.<br><br>Из леса выходит обросший, одичавший партизан. <br>- Эй, бабка! Немцы в деревне есть? <br>- Да ты что, милок? Вой https://www.opennet.me/openforum/vsluhforumID3/101997.html#97 Wed, 22 Apr 2015 01:35:20 GMT &gt; но может быть через какое-то время BTRFS и станет стабильной файловой системой. <br><br>Не скажу за RAID5/6, а остальное вполне работает уже сейчас.<br> <br>&gt; В OpenZFS не смотря на ее почтенный возраст до сих пор полно проблем и глюков:<br><br>Внезапно, в любой достаточно большой программе есть достаточное количество багов. И никакой маркетинговый булшит от санок не может это изменить.<br> <br>&gt; То же самое можно сказать и про Linux kernel - Linux является "всем",<br><br>За что его и ценят. Reuse знаний - в самых разных ситуациях.<br><br>&gt; и все что угодно. вот, даже роутеры делают на базе линукса - Mikrotik и т.п.<br><br>Если уж мы о софтороутерах, нынче ткни в каждый первый домашний роутер или точку доступа на полке магазина - и там с вероятностью 99% окажется пингвин.<br> https://www.opennet.me/openforum/vsluhforumID3/101997.html#96 Wed, 22 Apr 2015 01:27:12 GMT &gt; Вот на мой взгляд, это суровейшая антифича. Кому вообще в здравом уме <br>&gt; может захотеться обслуживать такой бардак?<br><br>Файловой системе. Для админов все просто и логично - файлуха делает ровно то что надо здесь и сейчас. Так как это надо здесь и сейчас. Если текущее комбо девайсов на это вообще способно. Для админа как раз все бует просто и прозрачно - прикидываем "ценность" vs "затраты на хранение" и выбираем схему для тех или иных файлов или иерархий (субволумов). Это как раз предельно логичный подход. Позволяющий хранить и видео с корп. пьянки и рабочие документы на одном хранилище. Но не переплачивая за резервирование того что юзеры перезалить могут и не возясь с новыми хранилищами. <br><br>&gt; Кому нужно разный уровень резервирования для разных данных, те положат их на <br>&gt; разные тома, каждый из которых находится на правильном raid'е<br><br>Вот была охота разводить лишние хранилища, одни под корп. пьянки, другие под рабочие документы. Вот как раз таким админстративным практикам место на свалке истории.<br><br>В btrfs