> Facebook will trial Btrfs in its "web tier" servers,
> explaining that's the easiest tier to recover if necessary

Вообще-то уже давно запилили. И Мэйсон радовался тому что в процессе попались несколько контроллеров, выдававших протухшие или недостоверные данные.

> - если упал какой-то сервер, его просто вытащили из кластера и заменили другим.

А это вообще нормальный подход к построению больших отказоустойчивых структур.

> Базы данных и другую критически важную информацию на BTRFS еще никто не хранит.

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

> вопрос был про ответственные и слишком ответственные применения.

А в ответственных - вы вообще готовы отвечать за какой-то левый побочный модуль ядра своей головой? Там поди еще и кернель потом будет tainted или около того, из-за лицензии модуля. Так что если будут какие-то проблемы - в майнлайне или где там еще могут просто послать в пешее эротическое: отвечать за глюки левого модуля никому не хочется.

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

Судя по... чему? Если так навскидку, я как-то не особо хочу отвечать за ядро с левыми посторонними модулями. За лажу в майнлайновых - можно причастных в майнлайне пинать. А с таким ядром - в майнлайне могут потом послать. А творцы стороннего модуля врядли готовы поддерживать все кернелы с этим модулем на уровне майнлайновых разработчиков.

> RAID5? Это они зря, http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/

Там есть несколько алгоритмов, на выбор. И возможность конверсии уровней на ходу. Если у кого всего 3-4 девайса - RAID5 будет оптимальнее по емкости чем зеркало и лучше по надежности чем отсутствие raid вообще. А если девайсов станет больше - можно потом и в raid6 переделать, например. Все это - на ходу, без остановки работы.

> RAID6 ситуация не лучше: http://www.zdnet.com/article/why-raid-6-stops-working-in-2019/

Авторитетный микрософтовский ресурс Зад Нет, вещающий про сферических коней в 2019 - это, конечно, круто. Но если что - btrfs на самом деле не очень принципиально, будет надо (==будет спрос) - прикрутят еще какую-нибудь схему аллокации. И перейти на нее можно будет на ходу.

> А BTRFS разве может? Это ведь точно такая же CoW файловая система.

Может. Пофайлово аж. Оракл был явно в курсе что CoW базам данных не друг, потому что идея журналить журнал и т.п. - дрянь. Поэтому видимо попросили (тогда еще своего) архитекта это учесть. И это было учтено. Так что обладатели всяких там БД имеющих свои понятия о журналировании/версионировании и виртуалок, имеющих свои понятия о CoW и снапшотах в своих виртуальных дисках - могут отключить CoW если он мешается.

> Кстати, с постепенным переходом на флеш CoW вообще перестанет быть проблемой.

Не перестанет. Если база пишет в журнал, а вы его CoW'аете, а потом еще и коммит в основную область отCoW'ать - получится жуткое месиво из фрагментов и метададанных, на SSD это конечно будет не так злобно тормозть. Но во первых ускорит протирание SSD ("write amplification" - на ровном месте), а во вторых - куча лишних операций и лопатинг кучи метаданных - медленнее при прочих равных.

Механика БД и дисков виртуалок подразумевает что файлуха просто патчит файл in place и на этом строятся все допущения о том как это будет работать. Эта механика плохо дружит с CoW, работая совместно работа умножится в несколько раз. Вот в этом случае CoW в btrfs можно отключить. Разумеется, при этом снапшоты и журналирование уже не совести такой программы. Но если программа хотела простую подложку, btrfs может стать таковой для вон тех файлов, если попросить.

> ZIL не мешает, а помогает делать запись более быстрой.

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

Намек был на то что если механика работы с файлом подразумевала простую не журналящую ФС, то CoW при этом может в целом оказать медвежью услугу.

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

У btrfs есть возможность дать то чего база хотела: тонкую прослойку без журналирования между базой и диском. При этом CoW данных для такого файла будет выключен, ФС станет тонкой подложкой позволяющей in-place патчи. Снапшоты для такого файла разумеется не будут работать. Но мысль откатывать базу путем отката снапшота ФС - сцыкотная, ведь ФС вообще ничего не знает про консистентность базы и ее администрирование. А гордость про то что в случае ZFS можно как-то изъ...ться и все-таки закрутить гвоздь любимой отверткой... ну с этим не ко мне. Я то вижу что там уместнее молоток. Вот у Криса Мэйсона в ящике с инструментом есть и это. А у саней - только маркетинговый булшит и сказки про то как вбить адовы костыли.

> Как и L2ARC - аналогичной возможности у BTRFS еще нет и даже не планируется...

В линухе есть уже чуть не полдюжины решений для кэширования на ssd. Насколько это надо именно в ФС а не блочном уровне... ну если RAID на уровне ФС может дать выставление ПОФАЙЛОВЫХ уровней избыточности, возможность при восстановлении сверять чексум и делать вывод какая копия верна, etc, а для всего этого ФС должна и рулить девайсами и свободным местом на них, так что менеджмент томов и райд смотрятся логично, то вот что дает вынос кэша на уровень ФС из блочного уровня - мне сходу не очень очевидно, если честно. Что дает awareness файлухи о всем этом, чтобы это считалось достоинством? Может потому и не спешат?

> Зачем дефраг на SSD накопителях?

На SSD в нем меньше смысла. Но нужда разбирать 100500 выносков по разным закоулкам может создать оверхед и там. Если уж мы о них - в ZFS нормальных экстентов нет. И то что btrfs вфигачит одним экстентом, ZFS будет оформлять кучей операций с блоками. Нафига оно вот так - саночники тоже рассказать не могут. Блоки переменного размера - не проще в реализаци чем нормальные экстенты, но менее эффективны по оверхеду, ибо весь смысл экстента в том чтобы оформить за один присест достаточно большой регион. Санки образцовые корпорасы: сделали сложно и с неважными эксплуатационными параметрами - одновременно.

> ZFS - это 128-битная файловая система для будущего.

Будущего, ага. Без нормальных экстентов, с кучей костылей, невозможностью вынуть диск из пула и убавить пул, где нельзя отключить CoW, намного менее гибкая чем btrfs в вопросах размещения данных и без перспектив выбора схемы хранения ("уровня RAID") на ходу, etc.

Санки - истинные корпорасы. Поэтому они заткнули кучу технических проблем громким маркетинговым булшитом. А в линухе нам вот нет никаких причин себя обманывать: btrfs же не соляра, делается для себя, а не на продажу в чистом виде.

В общем поменьше обращайте внимание на маркетинговый булшит и побольше - на то что и как фактически устроено и нафига оно вот так. Или вам нравится снимать маркетинговую лапшу с ушей?

> В XFS кстати, тоже нет уменьшения раздела.

"А в америке негров линчуют" - IT Edition :)

> Неужели эта feature так сильно нужна на серверах?

Гибкость в управлении storage space - визитная карточка btrfs. Вплоть до того что btrfs может оформить ext4 который был до него как свой первый снапшот, пристроившись "вокруг" ext4. А вот то что ФС должна создавать админу головняк дурными ограничениями на ровном месте для меня - не факт. Вот btrfs был сделан таким, чтобы учесть большинство неприятных и сложных моментов системного администрирования и сделать так чтобы ФС помогала, а не мешалась. Мне это весьма симпатично. А кто и по какому поводу добавляет и удаляет диски из пула - это его дело! И не дело ФС строить админа как ему там должно быть удобно. Вот у btrfs это буквально так: добавили диск, +N свободного места. Убрали диск, -N свободного места. Я нахожу такую схему управления девайсами логиной.

> Oracle - владелец исходных текстов и вполне мог бы
> перелицензировать при желании на GPL3 dual-license.

Насколько все это надо ораклу - оракл продемонстрировал. Путем запиливания btrfs :). Где сразу, еще на фазе проектирования и ранней реализации учтены неудобства CoW для БД и он сделан отключаемым. Я думаю что Oracle не требуется ZFS - настоящий next gen был запилен в виде btrfs.

> Но почему-то этого не делает. Наверное не хочет?

А оно им зачем? Btrfs появился как-то так: около 2007, IBM, Oracle и прочие - провели некое совместное совещание и решили что им всем нужна next-gen файловая система, которая вберет в себя лучшие черты существующих. Мэйсон посмотрел на то что уже существовало и на проблемы которые у всего этого были. И постарался надергать лучшее из сушествовавших дизайнов (включая ZFS), оставив за бортом недостатки. Я склонен считать что это более-менее получилось (хоть и не идеально, разумеется).

Судя по тому что нынче и по сей день есть немало народа с @oracle.com которые коммитят в btrfs, а сам оракль сватает Unbreakable Linux - подозреваю что от саней было надо клиентуру, а не технологии. Ну не друг ZFS базам данных, как минимум без серьезной переделки. Оракл это понимает, в отличие от лохов накормленых санями маркетинговым булшитом. Они то в курсе что их базам удобнее (в идеале - raw раздел, но это ж админить неудобно).

>> с пофайловой гранулярностью - мне кажется весьма перспективной.
> А в ZFS сейчас разве не так?

Насколько я понял - там все более-менее обычно. ZFS такой какой он есть - потому что в соляре не было кэша, менеджера томов и чего там еще. Вот они и запилили все в ФС. А в лине все это уже было на момент создания btrfs. Что привело к тому что в btrfs если что-то делали у себя - то потому что это давало какие-то качественно новые возможности, а не просто "чтобы было".

Rampant layering violation в ZFS - потому что в соляре не было менеджера томов. А в btrfs - потому что так можно было просто и естественно сделать пофайловый RAID с возможностью конверсии в любой момент без остановки пула, на ходу. Немного разная мотивация, со всеми вытекающими :)

> Кстати, Object-level RAID 0, RAID 1, and RAID 10 в BTRFS
> - это только планируют реализовать когда-то еще в будущем.

Да. Но дизайн структур все это позволяет уже сейчас. А когда оно конвертирует из одного уровня в другой - у пула одновременно есть 2 разных схемы хранения и все это при этом работает. Что и позволяет переделать уровень RAID на ходу: btrfs нормально относится к тому что половина chunks в такой схеме, а половина в этакой. Процесс конверсии просто берет chunk в старой схеме и переводит в новую. Все это может работать в фоне и ФС ни разу не смущается разными наборами chunks в разных схемах. Даже штатно там для данных и метаданных могут быть разные схемы хранения. Скажем на однодсковом пуле - для метаданных схема "dup", т.е. укладывание 2 копий метаданных в 2 разных региона по соображениям надежности. А для данных - схема "нифига".

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

Только они это придумали потому что в соляре не было менеджера томов. А в btrfs - потому что это дает новые возможности. Со всеми вытекающими отличиями.

> Этот менеджер томов можно использовать отдельно от файловой системы ZFS,

...что намекает на то, что это - тот самый менеджер томов, блочного уровня, которого не было в соляре. Всего лишь. А в линухе уже свой есть. Нафига еще один точно такой же надо? :)

А в btrfs RAID - интегрированная часть ФС, где за счет тесной интеграции ФС может пообъектно или как там еще выбирать схему хранения для конкретных файлов. Собственно из-за этого btrfs и имеет некоторые сложности с сообщением сколько осталось места. Ведь заранее неизвестно в какой схеме размещения будут новые файлы. Да и возможность размещения - зависит от девайсов и свободного места на них.

> разместив там например, Lustre или ext4 или все что может понадобиться:

У линуха уже есть LVM, нафиг ему еще и соляровый менеджмент томов сдался? Это функциональный дуп и по большому счету - лишний код. А в btrfs все это дает новые возможности - потому и не считается за дуп. Это не очередной менеджер томов, а пообъектный RAID в файлухе, интегрированная фича.

> В общем, кроме лицензии BTRFS ничем существенно не отличается в лучшую сторону от ZFS.

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