LINUX.ORG.RU

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

 , , ,


1

3

Canonical обещает предложить долгосрочную поддержку для файловой системы ZFS в Ubuntu 16.04 LTS которая будет получать заплатки безопасности и обновления в течение пяти лет, до апреля 2021, также ZFS будет файловой системой по умолчанию для контейнеров в Ubuntu 16.04 LTS.

На вопросы о возможном лицензионном конфликте Дастин Киркленд объяснил, почему это не является проблемой:

Эквивалентные исключения существуют уже много лет, для различных других автономных, самодостаточных, не GPL и даже фирменных (привет, nvidia.ko) модулей ядра. Наш вывод, что хорошо для пользователей Ubuntu, хорошо для Linux, и хорошо для всего свободного и открытого программного обеспечения

По мнению разработчиков различия в лицензии не мешают распространять поддержку ZFS в виде двоичного модуля или в виде исходного кода.

ZFS Licensing and Linux

ZFS is *the* FS for Containers in Ubuntu 16.04

В основу положен проект ZFS on Linux (он же OpenZFS)

★★★

Проверено: anonymous_incognito ()
Последнее исправление: anonymous_incognito (всего исправлений: 4)

Ответ на: комментарий от anonymous

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

intelfx ★★★★★
()
Ответ на: комментарий от anonymous

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

alkash
()
Ответ на: комментарий от intelfx

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

DALDON ★★★★★
()
Ответ на: комментарий от intelfx

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

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

DALDON ★★★★★
()
Ответ на: комментарий от anonymous

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

intelfx ★★★★★
()
Ответ на: комментарий от anonymous

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

intelfx ★★★★★
()
Ответ на: комментарий от DALDON

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

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

DALDON ★★★★★
()
Ответ на: комментарий от intelfx

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

DALDON ★★★★★
()
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

King_Carlo ★★★★★
()
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от DALDON

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

DALDON ★★★★★
()
Ответ на: комментарий от Novel

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

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

shlag
()
Ответ на: комментарий от anonymous

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

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

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

а это о чем? =)

shlag
()
Ответ на: комментарий от alkash

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

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

shlag
()
Ответ на: комментарий от intelfx

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

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

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

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

EvgGad_303 ★★★★★
()
Ответ на: комментарий от user_undefined

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

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

shlag
()

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

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

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

м? anonymous_incognito

anonymous
()

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

anonymous
()

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

anonymous
()

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

anonymous
()

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

xterro ★★★★★
()

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

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

Lavos ★★★★★
()
Последнее исправление: Lavos (всего исправлений: 1)
Ответ на: комментарий от shlag

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

alkash
()
Ответ на: комментарий от intelfx

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

EvgGad_303 ★★★★★
()
Ответ на: комментарий от alkash

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

anonymous
()
Ответ на: комментарий от alkash

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

anonymous
()
Ответ на: комментарий от King_Carlo

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

anonymous
()
Ответ на: комментарий от alkash

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

alkash
()
Ответ на: комментарий от alkash

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

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

Ygor ★★★★★
()
Ответ на: комментарий от alkash

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

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

anonymous
()
Ответ на: комментарий от shlag

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

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

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

Novel ★★★★
()
Ответ на: комментарий от vxzvxz

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

Gannet ★★★
()
Ответ на: комментарий от Novel

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

shlag
()
Ответ на: комментарий от alkash

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

anonymous
()
Ответ на: комментарий от Ygor

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.