>> В чем проще?
> Хоть в тех же экстентах.

Из-за того, что в файловую систему добавили новую сущность
- ее код от этого проще не становится, а только лишь наоборот.

> Блоки переменного размера - это не блоки фиксированного размера
> и работать с ними сложнее.

Разница только в том, сколько места на диске и в памяти будет занимать такой блок.

> А эффекта меньше чем от больших экстентов.
> Занафига оно такое?

Для transparent compression и дедупликации. С экстентами это не работает.

>> Откат снапшота == восстановление предыдущей версии базы данных из бекапа.
> Это, мягко говоря, не так.

С точки зрения базы данных - это так.

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

бекап файлов базы данных.

> Попытка все вот так под одну гребенку - попахивает ламерством, чтоли.
>> Вот точно так же надо останавливать базу данных и в случае отката снапшота.
> Я не знаю почему вы ставите в 1 ряд 2 совсем разных действа.

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

начало здесь:

https://www.opennet.ru/openforum/vsluhforumID3/101997.html#63

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

продолжение здесь:

https://www.opennet.ru/openforum/vsluhforumID3/101997.html#72

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

=====================================================

>>> У CoW всегда растут метаданные при перезаписях.
>> Не всегда.
> Простите? Чтобы старое состояние не разрушилось, надо делать новый выносок. Как вы
> себе представляете создание этого выноска без метаданных, которые описывают что это
> вообще такое и к чему это относится?

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

>> "The compression processes ranges of a file of maximum size 128 KiB" - как и в ZFS.
> А compression там, между прочим, тоже включается-выключается с пофайловой гранулярностью.
> Это не какое-то мегарешение раз и навсегда. А желаемый дефолт и
> желаемые оверрайды по месту. Очень хорошо сделано.

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

>> Они портируют BTRFS из линукса в солярис и полнсотью откажутся от использования ZFS ?
> Они будут сватать свои базы в паре с Unbreakable Linux, имхо.

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

Да и какой смысл ораклу уничтожать подразделение, которое приносит прибыль
и позволяет более-менее конкурировать с IBM`овскими серверами на рынке ?

> Ну и поддерживать btrfs. А ZFS и соляра им как таковые врядли нужны.

А ничего иного кроме соляры они на своих SPARC`овых серверах запустить не могут.

> А нафига еще они всякие там dtrace бэкпортируют на линух?
> Кому это надо кроме бывших солярщиков?

Ораклу и надо. Для создания vendor lock-in и видимых преимуществ перед RHEL,
у DTrace ведь лицензия такая, что запрещает включение этого кода в ядро линукса.

>>> В процессе наломали немало дров и сделали довольно спорный пепелац.
>> Сделай лучше.
> Это такое спервадобейся? А зачем?

Самый лучший способ доказать, что что-то было сделано плохо - это взять и сделать лучше.
вот как например, Линус Торвальдс доказал что Minix имеет проблемы в архитектуре
и вообще это не очень удачная реализация. Вместо того чтобы спорить на форумах.

> Мэйсон уже сделал, он это может лучше
> меня - мне нравится что я вижу, у него полет мысли
> повыше чем у санок будет. Таким и должен быть настоящий архитект
> next gen, имхо. А я что, мне просто нравится копаться в
> разных алгоритмах и разбираться как это устроено. Это не значит что
> я могу выйти и переплюнуть Мэйсона - у него весьма удачные
> tradeoff и большие перспективы.

Мэйсон еще не сделал, а только в процессе делания.
Кстати, до того Chris Mason работал в Namesys вместе с Шишкиным
над RaizerFS/Raizer4, и достаточно много идей в BTRFS утащил оттуда.

>[оверквотинг удален]
>> Если LVM Cache - тогда SSD будет быстрее изнашиваться, чем в случае использования L2ARC.
> Это на самом деле очень зависит от. Некоторые контроллеры SSD сами например
> жмут данные внутри SSD - в этом случае сжатие снаружи не
> повлияет на срок жизни SSD, т.к. с точки зрения чипов флеша
> объем данных вообще не изменится (встроенное сжатие не сможет сжать уже
> сжатые данные). Да и вообще, флеш - крупноблочные девайсы и там
> все сложно. Уменьшение объема записи - далеко не синоним уменьшения циклирования
> флэша, потому что есть еще write amplification. Но об этом имеет
> смысл рассуждать только если вы понимаете как работает флеш, что такое
> ERASE и PROGRAM, в чем проблема с erase blocks и прочая.

К чему такое большое количество слов и англоязычных терминов?

Если достаточно просто взять и посмотреть технические детали,
как устроен LVM Cache и как устроен L2ARC - тогда будет совсем
уже очевидно, какой из вариантов больше изнашивает SSD.

L2ARC хранит метаданные в памяти, LVM Cache - на диске.
Причем, LVM Cache будет апдейтить мелкие-мелкие блоки
в метаданных, так что write amplification будет в полный рост.

> А вот сделать core которое нормально относится к черти-какой смеси RAID
> и может на лету работать с смесью таковых и в принципе принимать решение
> на уровне конкретных файлов, subvolume ("часть иерархии") и прочая -
> это да, чувствуется полет мысли архитекта.

скорее уж опыт. как свой, так и учет опыта других файловых систем.
полет мысли на пустом месте редко бывает удачным.

> С другой стороны - я нормально отношусь к сборке автомобиля во время гонки.
> Это и есть опенсорс.

Бывают ситуации, когда нет возможности заниматься отладкой опенсорса
и хочется что-то более стабильное, и более надежное, CentOS, XFS, ZFS.

А BTRFS как появится в CentOS в полностью стабильном
виде - тогда и можно будет начинать им пользоваться.