> CoreOS Moves From Btrfs To EXT4 + OverlayFS

Оно как бы да, но эти хипстеры - весьма узконишевая штука и никакой особой погоды на рынке не делают, как минимум пока. А тот факт что их устраивает overlayfs вместо btrfs - прозрачно намекает что они фичами btrfs пользовались процентов этак на 5. С другой стороны, Мэйсон на предъявы ответил, вкоммитив в 3.19 порцию фиксов, которые как раз и чинят большинство из упомянутых проблем.

> WAFL/CoW превращает рандомную запись в последовательную, уменьшая количество IOPS.

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

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

Бонусом скорость линейного чтения например - уйдет в плинтус из-за кучи фрагментов (оверхед по метаданным + для механических винчей еще постоянный seek).

> Если устройства хранения - HDD - для них это должно дать прирост
> производительности.

Зато когда наступит момент эти данные читать, нас будут ждать неприятные сюрпризы.

> То есть, в BTRFS больше фич, значит BTRFS лучше за ZFS. Следуя
> такой логике, - Reiser4 будет еще лучше за BTRFS, потому что там можно
> писать свои плагины к файловой системе.

Задумано оно может и неплохо, но из разработчиков там аж целый 1 Шишкин, что как-то не дофига. А если поделить объем работ на объем работничков - слушайте, мой высохший скелет как-нибудь обойдется без файловой системы. Нафиг мне файловая система через пару столетий?

Кроме того плагины это здорово, но некоторые фичи получаются намного лучше когда это интегральные части core-дизайна. Ну как CoW или пообъектный RAID. Плагином такое сложно сделать без перепиливания половины core, с утерей совместимости по дисковым структурам. Не те вещи которые можно донавесить на соплях, сбоку.

> Подробнее об этом: http://habrahabr.ru/post/183230/ А в BRTFS нельзя.

В архитектуре софта главное - знать меру и вовремя остановиться. Вот с этим у Reiser4 не задалось.

> Эдуард Шишкин выступил с критикой Btrfs

Эдуард Шишкин взял какой-то ушибленный юзкейс в виде ФС на 600 мегов и кучей мелких файлов, не вдавался как btrfs устроен и получил ... ну то что получил. А на более реалистичных сценариях соотношения более другие. Да и кое-что из критики оптимизнули. Если на то пошло - любую ФС можно забить файлами нулевого размера до состояния когда вроде своболное место ни на что не потрачено, но новый файл создать почему-то нельзя. У одних кончится место из-за метаданных, у других и вовсе ограниченное количество inodes.

На мое нескромное мнение, Шишкин лучше бы в своем болоте разбирался - там проблем намного больше, как то полное отсутствие разработчиков при огромном объеме работ. В btrfs коммитит толпа народа, по поводу чего он уже более-менее достиг юзабельного состояния. А у Шишкина крЮтой PoC и половинка землекопа - на все работы. Так что я просто не доживу до того как оно станет пригодно к использованию.

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

Ни разу не видел нормального объяснения зачем блоки переменного размера сделаны так горбато и почему нельзя было нормальные экстенты сделать.

> Это точно такой же ZIL, только не вынесенный на отдельное блочное устройство.

И то и другое - по большому счету костыли CoW под некие частные случаи в которых чистый CoW как оказалось работает медленно.

> Из-да чего этот Log_tree из BTRFS будет гораздо менее эффективным чем ZFS ZIL.

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

А в случае с БД с nodatacow, btrfs вообще не будет журналить данные, раз БД или СoW-диск виртуалки сами с усами.

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

Не совсем. При пропадании 220V - процесс с БД будет перезапущен при старте системы или когда там оно надо, после чего БД делая стартовые проверки - заметит неконсистентность и прочая. Но при откате снапшота ФС - процессы базы по дефолту никто не перезапускает и что там получится - да Ктулху его знает. Вот вы на своих продакшеновых базах и проверяйте, если у вас стальные яйца.

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

Например, в том что откат снапшота не обязывает случиться рестарт процессов. Базы не проверяют в деталях консистентность и не делают реплей журнала ПОСТОЯННО. То-есть это как минимум требует сложных кастомных автоматизаций, с шатдауном и рестартом процесов после того как база ВНЕЗАПНО стала совсем другой.

И это подразумевает готовность к массовой потере всей информации, что накрывает семантику ACID медным тазом. Вы только что сказали клиенту что все оки-доки. И .. снесли его транзакцию откатом снапшота?! Зашибись. А дальше что?

> перед созданием снапшота и UNLOCK TABLES после создания оного - так еще лучше.

Все становится намного интереснее, если мы подумаем о том что случится при откате снапшота и насколько это вообще логически корректно и какие допущения при этом отвалятся.

Нет, с какими-то оговорками это можно, но с учетом всех возможных проблем + нагрузки по метаданным/фрагментам это выглядит крайне дурной и очень граблеопасной затеей.

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

Что однако не является поводом немедленно отбить себе все пальцы :)

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

Нельзя ли определение нормальности в студию?

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

Честно говоря - не вижу чем эта команда такая уж прямо замечательная vs все остальное. В любом случае это вкусовщина. У саней оно вот так просто потому что у них как я понимаю системных кэшей вообще не было. Ну вот и вперли все чего не хватало в соляре в ZFS. В каком-нибудь линухе это было в системе и половина фич ZFS там просто на..й не уперлась.

> 2) ZFS умеет делать компрессию данных в L2ARC, увеличивая производительность кеша

Ну ок, конкретно вот это - неплохо придумано. Но ниоткуда не следует что это должно быть частью ФС.

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

Тоже неплохо. С другой стороны все это по идее должно быть tunables. Мало ли какие там где носители и какие они будут в будущем.

>> Если уж мы о них - в ZFS нормальных экстентов нет.
> и нет проблем с ними связанных. см. выше "Эдуард Шишкин выступил с критикой Btrfs".

Зато есть другие. Экстенты используют потому что в типичных юзкейсах они ведут себя лучше чем другие решения. А то что какй-то Шишкин начнет изгаляться над 600Мб обрубком - btrfs малость не для этого делалась. По поводу чего ценность изысканий Шишкина актуальна для утонченных извращенцев. Вы впрочем в вашем праве разложить ZFS на 600Мб том и попробовать там поизвращаться а-ля Шишкин.

При сильном желании btrfs можно и на штуки типа sd-карты разложить, но там лучше использовать специфичные настройки (которые есть, как минимум - mixed block groups). По дефолту btrfs откусывает пространство накопителя довольно большими chunks, а chunk по дефолту приписан к конкретному варианту использования, т.е. для хранения данных. Или метаданных. На носителях малого объема где умещается всего несколько chunks - может выйти дисбаланс (в плане того что например невозможно записать данные, хотя свободное место как бы есть, но - в chunk для метаданных). Все это актуально для мелких носителей менее чем десяток-другой гигз размером, в более-менее типовых случаях все будет и по дефолту.

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

YOLO! Вы не поняли как CoW в ФСах обычно работает :).

CoW в ФС в общем виде делается как-то так: вы пишете изменение, допустим в середину файла. Классическая ФС записала бы это в середину файла (in place patching) и все этим закончилось бы. А CoW ФС выносит выносок с новыми данными куда-то вбок, в область свободного места. Старое содержимое файла - остается неизменным. Метаданные апдейтятся, чтобы текущая версия файла - строилась с заменой измененого куска на этот ваш новый выносок. В результате можно доступаться как к старому варианту файла, так и к новому - вопрос в интерпретации метаданных. Если взять старый вариант метаданных - можно получить старый файл. А новые метаданне = новый вариант файла. Btrfs делает CoW в том числе и для метаданных, что позволяет ему довольно легко проделывать такие фокусы.

Потом GC может при желании убить старый блок в середине файла, если старый вариант файла не требуется, освободив место в ФС (бесконечное хранение всех версий разумеется постепенно стрескает все место на стораже).

Как видите, копирование как таковое - не случается :). Точнее назвать это "неразрушающей записью". Но название устоялось, т.к. в некоторых реализациях таких алгоритмов запись идет in place, а копирование - старых данных, чтобы сохранить старый вариант. Но чаще оптимальнее если "копией" станет новый выносок, с новыми/измененными данными. А название вот осталось, потому что оптимизированный вариант той же идеи.

По этому поводу - CoW может делать снапшоты круто и быстро: для снапшота все уже есть на уровне дизайна. Остается только некую формальную пометку поставить, запрещающую GC чистить это - и снапшот готов. Фирменный caveat CoW: если безбашенно фигарить снапшоты, на стораже однажды кончится место, хотя суммарный объем файлов далек от объема стоража. Место уйдет на хранение "отличий от снапшота". По этому поводу снапшоты стоит переделывать/подтирать старые.

Вообще, есть ряд выводков технологий которые очень похожи и по сути разновидность одной идеи. Как несложно заметить, то что делает CoW можно рассмотреть как "бесконечный журнал", занимающий весь стораж (области данных просто нет). А реплей журнала до энного состояния - дает энное состояние файла. Новое состояние - строится дозаписью журнала. Commit в область данных отсутствует, откуда и профит в скорости записи: двукратной записи - нет, а журнал - есть. По этому поводу можно повстречать "log-structured" ФС/БД/чтотамеще.

А поскольку такие технологии имеют потенциал для хранения нескольких версий файла (записи БД, ...) - можно повстречать это и под названием "версионник".

Реально у тех или иных вариантов могут быть те или иные детали реализации, но общий смысл всех вариантов такой что при записи возникает как старая версия, а запись не разрушает (сразу) старое состояние и оно останется доступно (некоторое время).

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

Ога, тут весь форум забит радостями от аппетитов дедупа :)

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

Пусть он имхо лучше свою ФС до ума доводит чем страдает извращениями с 600Мб томом btrfs. Если кто еще не понял - положить на лопатки извращениями с краевыми условиями можно вообще любую ФС. Поэтому ценность изысканий Шишкина невелика: вопрос то скорее в том как ФС работает в более-менее обычных, часто встречающихся задачах, а btrfs на мизерном томе - это скорее экзотика. Btrfs достаточно нормально работает на томе человеческого размера, в грязь лицом так уж откровенно не падает. CoW имеет некие отличия от "классических" ФС по свойствам, но если их понимать - все оки-доки.

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

Про все. Как они например диск из пула вынимать собираются? Они таки будут хранить backrefs? И что там насчет совместимости?

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

Бывает так что все файлы кроме 1-2 (ну там БД какая-нибудь) - нормально относятся к CoW. Вот в btrfs можно адресно отключить CoW для файлов где это создает проблемы и пользоваться преимуществами CoW на всем остальном. Гибкость ФС это хорошо. А метаться с ФС на ФС по причине "два файла не очень дружат с CoW" - как-то глупо. Вот оракл довел это до сведения своего архитекта и тот это весьма качественно учел. И вот такой подход мне как-то сильно более симпатичен чем ваши юления ужа на сковородке. Вот это - лицом к админам, а не тыловой частью.

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

А вы прямо так пошли и опросили всю планету - какие кому фичи нужны?

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

Хз. На компьютере с которого я это пишу, btrfs является root FS (да, я не боюсь кушать то что нахваливаю). Вот уже полгода как оно работает а данные все в наличии. Хотя и питание некорректно слетало, и кернель я пару раз вешал наглухо экспериментами, и что там еще. Понятно что баги есть везде, но как видим - в целом вполне работает. Но да, лучше использовать максимальное свежее ядро.

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

Для меня это не видится большой проблемой, не говоря о том что для линуха решений по кэшированию - чуть не полдюжины. ИМХО я лучше буду иметь дело с btrfs чем с древним дизайном "ни два ни полтора", где нормальные экстенты - не смогли, изъятие диска - навороты и круть, которая будет доступна как-нибудь потом, дефрага - нет, переделать на ходу уровни RAID - фигушки, равно как и отключить CoW если мешается. А на все вопросы - ответ цитатами маркетингового булшита от санок. Мне такое не надо, спасиб. Зачем мне себя обманывать?

>> (в идеале - raw раздел, но это ж админить неудобно).
> Для BTRFS + LVM Cache приходится ведь использовать raw разделы и ничего, нормально.

Одно дело какой-то там кэш и другое - БД так админить.

> Rampant Layering Violation?

Он самый. Только в ZFS он "потому что в соляре ничего не было", а в btrfs - "потому что при таком дизайне лучше работало и стали доступны новые возможности и перспективы". С точки зрения линуха, половина кода ZFS нафиг не упало - у линуха свое это уже было. И менеджер томов, и управление памятью кэша, и что там еще.

> Solaris Volume Manager

IIRC, ZFS делался достаточно давно и вот тогда у них как раз и не было ни кэша, ни управления томами. Что отлилось в ряд странных подсистем в ZFS, которые не имеют большого смысла где-то еще.

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

При чем тут btrfs? У btrfs свои, очень кастомные понятия о том что такое RAID. А у ZFS - более-менее обычные.

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

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

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

Вот такие: вы тут тыкаете ссылками и пересказами на тот маркетинговый булшит который сани втирали еще в эпоху втюхивания соляры, до того как они ораклу продались. Суперкомпетентное комьюнити очковтирателей от соляры подхватило и побежало пересказывать. Ну, типа вас, которого не понимает как CoW в файлухах работает, но уже имеющего ценное мнение. И постоянно пытающегося мне показать ссылки (которые я сто лет как видел до вас). Пфффффф. Такое соотношение апломба и неумения думать и понимать системные процессы - это suxx, мистер.

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

Поверьте, я в состоянии найти FAQ на ZFS. Только вот солярщики вообще и фаны ZFS-а исторически зарекомендовали себя редкостными спиди-гонщиками. Компенсирующими технологические продолбы и упущения громкими маркетинговыми слоганами, по поводу чего объективность сведений зачастую очень хромает. А вот лично вы - попались на том что имея мнение и давая ценные указания - ни в зуб ногой как CoW в ФС работает. Ну, знаете ли, мне кажется что до того как рассуждать о преимуществах и недостатках - надо более-менее понять что вообще происходит и почему, а? По каким-то таким причинам - я совершенно не горю желанием иметь какие дела с солярой и ZFS. Комьюнити вокруг всего этого - "не очень", скажем так. В плане апломб vs квалификация.