Canonical объявила о поддержке файловой системы ZFS в Ubuntu 16.04 LTS

Потому что xfs и ext4 имеют нормальную производительность при работе с образами дисков гостевых машин. А btrfs, zfs и reiser4 — нет, т. к. все построены по принципу copy-on-write, что приводит к дикой фрагментации файла при множественных записях в середину файла.

В zfs не будет дефрагментации, т. к. не будет block pointer rewrite, про что написано в блоге одного из разработчиков zfs. В reiser4 не будет дефрагментации, т. к. некому этим заниматься.

Потому что xfs и ext4 имеют нормальную производительность при работе с образами дисков гостевых машин

мы же договорились, что на опыт плюём, не?

reiser4 — нет, т. к. все построены по принципу copy-on-write,

вобщем, изучай матчасть. Reiser4 никто не строил по принципу copy-on-write. Там гибкий подход с заданием транзакционных моделей.

Ссыль можно? А то одного разработчика ZoL носом в дефрагментацию натыкал в августе прошлого года.

В reiser4 не будет дефрагментации, т. к. некому этим заниматься.

а ты часом не оракул ли?

Есть в этих вот Интернетах, тесты kvm на ext4,zfs,btrfs - btrfs сливается совершенно полностью. А зачем ещё может потребоваться btrfs - ума не приложу. Прозрачное сжатие, снепшоты - да. Но это уже всё есть в zfs, и работает быстрее. Что-то RHEL не торопится btrfs внедрять куда-либо. Но в zfs, есть ещё киллерфича: vol. Чего насколько я понимаю нету в btrfs.

Более того, в btrfs есть дефрагментация, в то время как в остальных ФС её нет и никогда не будет, поэтому btrfs в этом юзкейсе на самом деле даже лучше zfs

Не посмею спорить. Не знаю как в btrfs, но в zfs, частично это нивелируется: zlog и larc2 - ssd девайсами.

Я знаю про транзакционные модели и хотел про них дописать, но время редактирования истекло. txmod=journal — это исключение.

Я почти лично знаю всех тех двух человек, которые за последний год присылали хотя бы один патч в reiser4, и совершенно точно уверен, что ни один из них не собирается в ближайшее время писать дефрагментацию.

l2arc работает, ЕМНИП, только на чтение, а zlog - только с синхронными записями (т. е. он улучшает latency, а не throughput).

Теоретически, zvol должны ровно настолько же тормозить, как и .img на btrfs.

l2arc работает, ЕМНИП, только на чтение

Всё верно. Это слегка нивелирует фрагментированность.

zlog - только с синхронными записями (т. е. он улучшает latency, а не throughput).

Всё так. По-этому и написал я, что: частично нивелируется. То есть, мы меньше пристаём к физическим НЖМД, за счёт того, что читаем с SSD когда можем, и чуть меньше дёргаем при записи. Как-то так. :)

Не буду сильно умничать, но это похоже не совсем так. А точнее совсем не так. zvol - как блочное устройство поддерживает O_DIRECT, и kvm может производить запись, минуя кеш хост ОС. - Проверил на практике, действительно, zvol работает быстрее, чем тоже самое положить в виде img - на ext4/zfs. Предположу, что btrfs, будет давать (в лучшем случае), производительность как ext4. Всё же zvol, на 20 процентов (как минимум, в моих тестах), оказывается быстрее.

http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-an...

Мой собственный опыт это подтверждает btrfs абсолютно непригодна для хранения образов-ВМ, производительность неприемлемо низкая.

zvol - как блочное устройство поддерживает O_DIRECT

Хм. Ясно. Они хранят данные в целых блоках и умеют отключать CoW.

Я не пробовал, можно ли делать O_DIRECT в файлы на btrfs, для которых отключено сжатие и CoW (chattr +Cc), но в любом случае тогда это имеет шансы быть быстрее, чем btrfs.

Где-то читал, что btrfs, так же как и собственно zfs - не умеют O_DIRECT совсем. zfs, только на блочном ус-ве.

zvol удобно как блок девайс в виртуалочку засунуть. снапшоты делать, send/recv, все дела.

Мне больше нравится zfs в роли корня, чтобы из самой виртуалки рулить всеми делами. Но, если использовать корень на zfs на виртуальном диске, представляющем из себя zvol, то скорость работы этого монстра стремиться к нулю (это страшилки про солярис, конечно).

В основном для thin provisioning (который никогда в LVM толком не работал)

Тут, на мой взгляд, zvol не очень корректно сравнивать с томом lvm. zvol больше похож на файл на ФС, а у файлов с thin provisioning порядок.

и для акцидентного использования блочных дисковых устройств.

а это о чем? =)

Обоснуй, почему к сожалению?

Как минимум, для zfs не нужно было бы ничего доустанавливать/дособирать при использовании ядра отличного от стандартного ядра дистрибутива.

Вообще, принципиальная проблема zvol

Можешь считать zvol как raw device.

это вообще (почти) никогда не так.

Если это не синхронная запись, то ман txg timeout у zfs.

В доке просто хотят предостеречь от переоценки вклада процедуры хеширования в общее время дедупликации на лету.
Кроме того, дока уже не свежая, значения абсолютные. Диски стали быстрее, - да, но процессора тоже не стоят на месте.

Когда речь заходит речь о высоких требованиях к латентности на запись, дедупликацию, вообще, лучше не включать.

Canonical обещает предложить

Оффтопик-лист, пункт 2:

Новости о намерениях что-либо делать (переходить на Linux и т.п.). Вот сделают, тогда и обсудим.

м? anonymous_incognito

Все понятно с вами. Вы за монолит и GPLONLY.
Я категорически против этой религии.

Ляликсоеды теперь обосрутся от счастья.

Прикольно, что когда вся прогрессивная общественность использовала ZFS на FreeBSD, ляликсоеды писали что-то там про свой btrfs, а как им пообещали только zfs, так вон какая бурная реакция и улюлюканье!

Это лишний раз доказывает, какие ляликсоиды тупые и кушают всё, что им подадут, будь то сраный ext4 или ещё какое УГ

Что это даст простому пользователю(использование этой ZFS) по сравнения с Ext4, используемой сейчас by default?

Ровным счетом - ничего хорошего.
Из плохого - пример

Я считаю, что новая ФС нужна.

«Эта файловая система объединяет концепции файловой системы и менеджера логических дисков (томов) и физических носителей, новаторскую структуру данных на дисках»

Ужас, Поттеринг и до FS добрался?

HAMMER

Тем временем давно есть https://ru.wikipedia.org/wiki/NILFS, но никто не пользуется )

Нет, ну с writeback-кэшем всё понятно. А когда его флашить нужно, подсистеме I/O придёт песец.

Нет, я за стабильность работы и простоту сопровождения.

Что по вашему стабильность? И простота сопровождения?

Ты нипонил, txg timeout по дефолту 5 сек, т.е. оно искаропки пишет последовательно по 5 сек. С синхронной можно добиться того же используя slog на отдельном устройстве.

Типичный синдром утёнка - «ололо, мой любимый ext4 — это всё, а zfs — какаха». Просто погуглить не можешь и посмотреть, какие у неё преимущества. Ну а что на ляликсе не умеют её готовить, это не удивительно

Я пришёл к выводу, что HAMMER не нужен, особенно HAMMER2. Не так там много вкусного, кроме чего-то частично похожего на версионность

Судя по описанию очень похоже на HAMMER

Ты о чем? О моих знаниях ZFS? Так ты ошибаешься, что я ее не знаю и боюсь использовать.

И с чего ты решил, что там нет преимуществ? Не говоря о такой обычной вещи, как снепшоты, как мне без zfs и без лишних телодвижений заменить харды на более ёмкие и не потерять данные? А тут заменил по одному, подождал, пока resilver закончится, увеличил размер зеркала и готово. И при этом твои данные всегда доступны. Если SATA hotplug поддерживается твоим железом, то и компьютер выключать не надо. И не надо никаких правок /etc/fstab, перезагрузок, перенастроек и прочего гемора.

Плюс ко всему зеркало спасёт твои данные, если с хардами реально случится что-то плохое

Я в курсе. Я ее использую. Только не в linux, а в FreeBSD использую ZFS.
ZoL попробовал и... Написал предъяву разработчику. Носом в тесты натыкал. Это перебор - 64% фрагментация и скорость чтения упала до 6 Мбит/с. Диск в прямом смысле слова трещал.

Хаммер, академическая поделка, настолько перспективная, что за многолетнюю историю её существования никто так и не решился ни куда её перенести со стрекозы.

Лирическое отступление: UFS2 уже чёрти столько из коробки на FreeBSD поддерживает снапшоты.

Носом в тесты натыкал.

Натыкай меня тоже носом в тесты.

Мне больше нравится zfs в роли корня, чтобы из самой виртуалки рулить всеми делами. Но, если использовать корень на zfs на виртуальном диске, представляющем из себя zvol, то скорость работы этого монстра стремиться к нулю (это страшилки про солярис, конечно).

zpool на zvol'ах вообще из фрибзд чуть не выпилили недавно:

https://svnweb.freebsd.org/base?view=revision&revision=294329

Вот чё ты херь тут пишешь? Иди лучше погуляй где-нибудь.

Во фряхе все ж другая тема: функциональные проблемы при размещении zpool на zvol в пределах одного экземпляра ОС. Я сталкивался с плохой производительностью при презентации zvol в качестве виртуального диска ldom'у и размещении внутри гостевого домена zpool'а на этом диске.
В любом случае, такая конфигурация нежизнеспособна.

А, в этом плане. Так не удивительно. Я тоже только на фряхе и использую

Тоже пиздёж. HAMMER вполне себе Ъ, но по сравнению с ZFS он особо и не нужен.