> А чем экстент фундаментально отличается от блока переменного размера,
> с очень большим максимальным размером? У zfs трабл в этом самом размере,
> что обрекает их ворочать немало метаданных даже в случае когда можно
> было бы просто вкатить все одним регионом, с компактным и быстрым
> описанием. Наверное поэтому оно так и выглядит в бенчах vs btrfs. CoW и экстенты плохо совместимы между собой.
У ZFS - более простой и надежный код в этом месте,
ценой некоторого уменьшения производительности.
У BTRFS - попытка сделать файловую систему и максимально фичастой
и максимально производительной, что ведет к усложнению алгоритмов и кода.
А если код сложный - в нем может быть больше нетривиальных ошибок и глюков.
Если надо "ехать" - тогда ZFS выглядит более привлекательно,
Если нужны "шашечки" - тогда более привлекательно выглядит BTRFS.
> А можно вот как-то на уровне ФС сжульничать с чем-то типа снапшотов,
> freeze/thaw и прочая, чтобы избавиться от постоянной записи в бэкапируемый файл.
> Но если это без явного подыгрыша со стороны БД, вы все-равно получите базу
> и журналы в состоянии "как было". Т.е. запросто на середине какой-то транзакции
> в процессе. Это не консистентная копия БД. Если такой бэкап БД подсунуть,
> БД должна сделать аварийное восстановление с реплеем журнала и откатом/докатом
> транзакций, как после краха системы.
Правильно. После чего база данных переходит в консистентное состяние.
> В общем это интрузивные и граблеопасные действия
> и наобум ворочать это снапшотной механикой файлухи - весьма спорное развлечение.
В чем именно "граблеопасность" ?
> Такому "бэкапу" в общем случае надо будет как
> минимум реплей журнала как после жесткого краха.
База данных это сделает самостоятельно.
=========================================
>>>>> У CoW всегда растут метаданные при перезаписях.
>>>> Не всегда.
>>> Простите? Чтобы старое состояние не разрушилось, надо делать новый выносок. Как вы
>>> себе представляете создание этого выноска без метаданных, которые описывают что это
>>> вообще такое и к чему это относится?
=========================================
>> Например, если нет снапшотов - метаданные файловой системы просто меняются но не растут.
> А, вы кажется начинаете догадываться почему в btrfs сделали CoW отключаемым
Нет, я говорю о том, что ваше утверждение
"У CoW всегда растут метаданные при перезаписях"
ошибочно и не соответствует действительности.
> Судя по активному развитию Unbreakable Linux - оракл оказался
> как-то совсем не против барыжить и линухом на х86.
Нет никакого "активного развития Unbreakable Linux" - оракл просто ворует результаты
работы Red Hat и пытаются заработать, продавая техническую поддержку к чужому продукту.
> долговременные перспективы - в unbreakable linux
нет никакого "unbreakable linux", это на 100% маркетинг и обман.
> В линухе вон сколько народа систему пилит. А в соляре только сам оракл.
> Им это сильно надо? Мне как-то кажется что не очень, капиталисты - жадные.
Странно, почему ж тогда майкрософт не откроет исходники виндовса под лицензией GPL ?
> Архитектура у линукса далеко не лучшая.
> Но от операцоинки всем надо не супер-архитектуру.
ошибки в архитектуре очень дорого обходятся. например:
http://habrahabr.ru/post/53048/
http://habrahabr.ru/post/179333/
>> Причем, LVM Cache будет апдейтить мелкие-мелкие блоки
>> в метаданных, так что write amplification будет в полный рост.
> во первых для линукса есть несколько вариантов кэшей.
ладно, какой из этих вариантов лучше всего подходит для использования с BTRFS ?
из стабильных в RHEL есть всего один вариант, - это LVM Cache.
> Во вторых что там реально будет происходить и как это отмаппится в фактические
> erase/program - очень сложный вопрос, точно просчитать это вообще невозможно.
> Можно лишь грубо прикинуть на основе знаний как работает флэш и что ему удобно,
> но все-равно остается много неизвестных в уравнении и делать громкие заявления
> на песке - это так по сановски...
еще раз:
LVM Cache хранит на SSD как данные кеша, так и метаданные.
метаданные - это мелкие блоки информации.
L2ARC хранит на SSD только данные, а метаданные хранятся в памяти.
еще не очевидно какой из двух вариантов кешей будет меньше
изнашивать SSD и давать большую скорость работы с кешем ?