>> ZFS судя по всему, там использовать уже можно, а вот BTRFS - еще нет.
> Судя по... чему?

Например,
http://www.phoronix.com/scan.php?page=news_item&px=CoreOS-Bt...
CoreOS Moves From Btrfs To EXT4 + OverlayFS

>> А BTRFS разве может? Это ведь точно такая же CoW файловая система.
> Может. Пофайлово аж. Оракл был явно в курсе что CoW базам данных
> не друг, потому что идея журналить журнал и т.п. - дрянь.

WAFL/CoW превращает рандомную запись в последовательную, уменьшая количество IOPS.
Если устройства хранения - HDD - для них это должно дать прирост производительности.

> Так что обладатели всяких там БД имеющих свои понятия
> о журналировании/версионировании и виртуалок, имеющих свои понятия
> о CoW и снапшотах в своих виртуальных дисках - могут отключить CoW если он мешается.

То есть, в BTRFS больше фич, значит BTRFS лучше за ZFS. Следуя такой логике, - Reiser4
будет еще лучше за BTRFS, потому что там можно писать свои плагины к файловой системе.
Подробнее об этом: http://habrahabr.ru/post/183230/ А в BRTFS нельзя. Тем более, что:

https://www.linux.org.ru/news/kernel/5041798
Эдуард Шишкин выступил с критикой Btrfs

>> ZIL не мешает, а помогает делать запись более быстрой.
> Я про механику в целом. ZIL - обычный костыль, при том саночники
> даже толком не могут сказать зачем они все это делали вот
> так и почему в целом получилось так наворочено, но при этом
> - довольно бестолково по параметрам.

Вроде бы все очевидно, зачем они это сделали. Да и объяснено уже не раз.

>> У BTRFS есть аналогичная feature, только тут она не вынесена на отдельный SSD,
>> так что толку от нее будет не много: https://en.wikipedia.org/wiki/Btrfs#Log_tree

Это точно такой же ZIL, только не вынесенный на отдельное блочное устройство.
Из-да чего этот Log_tree из BTRFS будет гораздо менее эффективным чем ZFS ZIL.

> Но мысль откатывать базу путем отката снапшота ФС - сцыкотная,
> ведь ФС вообще ничего не знает про консистентность базы и ее администрирование.

Для нормальных баз данных не должно быть проблемой создание снапшота файловой системы
в любой момент. Просто потому, что это будет эквивалентно резкому пропаданию 220V
в момент работы с базой данных.

Потом - база данных откатывает из лога транзакций незавершенные трензакции
и возвращается к полностью косистентному состоянию. В чем проблемы ? Не понимаю.

Тем более, что некоторые базы данных умеют FLUSH TABLES WITH READ LOCK
перед созданием снапшота и UNLOCK TABLES после создания оного - так еще лучше.
Подробности: https://www.lullabot.com/blog/article/mysql-backups-using-lv...

> там уместнее молоток. Вот у Криса Мэйсона в ящике с инструментом есть и это.

"Когда у тебя в руках молоток, все задачи кажутся гвоздями".

>> Как и L2ARC - аналогичной возможности у BTRFS еще нет и даже не планируется...
> В линухе есть уже чуть не полдюжины решений для кэширования на ssd.

Из нормальных - только LVM cache.

> Что дает awareness файлухи о всем этом, чтобы это считалось достоинством?

1) Проще и удобнее для пользователя сказать
# zpool add pool_0 cache c7t0d0 c7t1d0 c8t0d0 c8t1d0 c9t0d0 c9t1d0
в командной строке, чем играться с настройкой lvm cache.

2) ZFS умеет делать компрессию данных в L2ARC, увеличивая производительность кеша
http://wiki.illumos.org/display/illumos/L2ARC+Compression

3) запись в L2ARC происходит большими блоками, чтобы зря не изнашивать SSD

> Если уж мы о них - в ZFS нормальных экстентов нет.

и нет проблем с ними связанных. см. выше "Эдуард Шишкин выступил с критикой Btrfs".

> И то что btrfs вфигачит одним экстентом, ZFS будет оформлять кучей операций с блоками.

Каким образом BTRFS сделает CoW при этом? Будет копировать весь большой экстент?

> Нафига оно вот так - саночники тоже рассказать не могут.

Могут и рассказали: https://blogs.oracle.com/bonwick/entry/zfs_dedup

> Блоки переменного размера - не проще в реализаци чем нормальные экстенты, но менее
> эффективны по оверхеду, ибо весь смысл экстента в том чтобы оформить
> за один присест достаточно большой регион.

см. выше "Эдуард Шишкин выступил с критикой Btrfs".

>> ZFS - это 128-битная файловая система для будущего.
> Будущего, ага. Без нормальных экстентов, с кучей костылей

про какие костыли идет разговор?

> где нельзя отключить CoW

Если нужна файловая система без CoW - проще будет именно ее и взять, например, XFS.

>> В XFS кстати, тоже нет уменьшения раздела.
> "А в америке негров линчуют" - IT Edition :)

Нет, это просто к тому, насколько сильно такая фича кому-либо нужна.

> Гибкость в управлении storage space - визитная карточка btrfs.

Как и глюки, которые приводят к повреждению файловой системы.

> А вот то что ФС должна создавать админу головняк дурными ограничениями
> на ровном месте для меня - не факт.

Но ведь будет создавать, потому что для использования BTRFS на HDD + SSD для кеша
надо будет кроме BTRFS использовать еще и LVM и LVM Cache - приятного в этом мало.

> Они то в курсе что их базам удобнее
> (в идеале - raw раздел, но это ж админить неудобно).

Для BTRFS + LVM Cache приходится ведь использовать raw разделы и ничего, нормально.

> Rampant layering violation в ZFS

https://blogs.oracle.com/bonwick/en/entry/rampant_layering_v...
Rampant Layering Violation?

>> Так это в ZFS и придумано было. И не только придумано, но и реализовано.
> Только они это придумали потому что в соляре не было менеджера томов

Solaris Volume Manager

> У линуха уже есть LVM, нафиг ему еще и соляровый менеджмент томов сдался?

В таком случае - придется делить диск между LVM и BTRFS,
в том числе и размещая BTRFS на LVM разделах, что не добавит
ни производительности ни простоты/удобства работы с дисковой подсистемой.

> В общем, маркетинговый булшит маркетнговым булшитом

"маркетинг" - это вроде бы от слова "продажи".

а какие могут быть продажи, если OpenZFS - это open source софт?

> чтобы всенепременно втюхать, как санки

Какие санки? Новость вообще-то про http://en.wikipedia.org/wiki/OpenZFS

Подробнее про линуксовый вариант: http://zfsonlinux.org/faq.html