>>а типа в ZFS СoW только для одного из двух?
>
>Насколько я помню - в ZFS есть ZIL, по смыслу похожий на
>традиционный журнал.Ну разве что только по смыслу в какой-то мере.
> И хотя дизайн самого ZFS далек от обычных ФС,
>собссно, предполагаемые транзакции пишутся в ZIL, что по смыслу действа как
>я понимаю все-таки смахивает на обычное журналирование.
Что такое транзакция в контексте ZFS, точнее ZPL, и ZIL представляете? Это фактически системный вызов, изменяющий состояние ФС, типа write(), unlink() и т.д.
Так вот, информация о каждом системном вызове записывается в ZFS Intent Log в оперативной памяти, причем записывается очень компактно - в высокоуровневых терминах - идентификаторы изменяемых объектов, вносимые изменения, а не в дисковых блоках и их содержимом. Зачем это делается и почему в памяти? Затем, что заранее неизвестно, будет ли использован после какого-то набора операций вызов fsync() или нет. Для файлов, открытых в синхронном режиме, это известно заранее, но это не меняет сути.
Когда приходит fsync(), ZFS проходит по этому журналу в памяти и формирует из записей об отдельных транзакциях для данного файла блоки, в которые может упаковываться информация о нескольких транзакциях из ZIL в памяти, и уже эти блоки пишет на диск, формируя на диске связанную цепочку таких блоков, прицепленную к ФС.
> И при этом работает все-таки не CoW.
Кто сказал? ZFS никогда не пишет новые блоки в еще занятое место. Запись новых блоков выполняется в свободное место, и ZIL здесь не исключение. Блоки для ZIL выделяются либо из свободного пространства в пуле, или же используются специально выделенные для этого устройства (LogZilla), с возможностью отката на использование блоков пула, если устройства для ZIL, скажем, выходят из строя.
Как только все блоки необходимые блоки записались на диск, системый вызов fsync() возвращает управление вызвавшему его пользовательскому процессу.
Когда закрывается группа транзакций, в которую была назначена транзакция, соответствующие записи из ZIL в памяти удаляются, а дисковые блоки освобождаются.
Если происходит сбой, то возникает необходимость прочитать блоки с записями о транзакциях ZIL с диска (и это единственный случай, когда они читаются), и повторить записанные в них транзацкии путем вызова соответствующих функций уровня VFS.
> Кстати если вы такой уж супергуру - объясните
>нафиг они так сделали? Грубо говоря: нафиг вообще им был нужен
>ZIL если можно влобовую юзать CoW обладающий удобными (с точки зрения
>недеструктивности операций) свойствами.
Затем же, зачем так делает та же ваша btrfs. Фиксация группы транзакиций (full tree commit) в терминах btrfs) - операция дорогостоящая, из-за необходимости CoW для большого количества блоков косвенной адресации.
>В бтр насколько я понял ничего такого вообще нет - корректность и
>данных и метаданных просто в лобовую обеспечивается CoW-механикой (для этого деревья
>метаданных были несколько переделаны, чтобы хорошо накладываться на логику работы CoW).
Похоже, вы кое-что читали о btrfs, но по-диагонали. Там основная хитрость - учет количества ссылок. А для синхронных операций (fsync, O_DSYNC) используется подобный же механизм (tree_log.c):
105 /*
106 * tree logging is a special write ahead log used to make sure that
107 * fsyncs and O_SYNCs can happen without doing full tree commits.
108 *
109 * Full tree commits are expensive because they require commonly
110 * modified blocks to be recowed, creating many dirty pages in the
111 * extent tree an 4x-6x higher write load than ext3.
112 *
113 * Instead of doing a tree commit on every fsync, we use the
114 * key ranges and transaction ids to find items for a given file or directory
115 * that have changed in this transaction. Those items are copied into
116 * a special tree (one per subvolume root), that tree is written to disk
117 * and then the fsync is considered complete.
118 *
119 * After a crash, items are copied out of the log-tree back into the
120 * subvolume tree. Any file data extents found are recorded in the extent
121 * allocation tree, and the log-tree freed.
122 *
123 * The log tree is read three times, once to pin down all the extents it is
124 * using in ram and once, once to create all the inodes logged in the tree
125 * and once to do all the other items.
126 */
>Ну и в случае сбоев - ФС возвращается в корректное состояние
>сугубо силами CoW-механики.
Представление не вполне верное - CoW просто позволяет взять последнее полностью зафиксированное на диске состояние, ничего никуда не возвращая, а просто используюя его в качестве начального. А вот возвращение файлов, с которыми велась работа в синхронном режиме, в состояние, гарантированное приложению, происходит уже путем проигрывания записей из этого лога.
> Если меня не подводит склероз оно возвращает и
>данные и метаданные в вид который был на момент последнего успешного
>чекпойнта а временные чекпойнты просто делаются на автомате периодически, IIRC, раз
>в 30 секунд фигачится такой вот "временный снапшот". Не слишком сложно
>и вполне логично и симпатично.
Ну да, только базам данных задержка в 30 в секунд на коммит транзации вряд ли подойдет.
>Влобовую сравнить в этом аспекте zfs и btrfs трудновато из-за весьма разного
>устройства (сани в zfs вообще такого нагородили что там черт ногу
>сломит).
Насчет "такого нагородили" - это вы сами для себя поняли, или напел кто? Не так страшен черт, как его малюют ;-)
В btrfs разбираться это тоже не фунт изюма - там около 52 тысяч строк кода только в кернельной части (в ZFS, правда, около 91 тысячи, но это с учетом последних вкусностей типа дедупликации и прочего).
>> Матчасть надо бы подтянуть, прежде чем имхами делиться...
>
>Я для этого пользовался чем-то типа http://www.opensolaris.org/os/community/zfs/docs/ondiskforma... .Но он не слишком подробно
>освещает вопросы журналирования и вообще, я слегка свихнул мозг на этом
>дизайне ФС. Понагородили же! И так и не понял почему некоторые
>аспекты были сделаны достаточно странно и своеобразно - имхо получилось как-то
>чрезмерно навороченно и странно. Если вы можете показать RTFMник лучше, велкам,
>покажите.
Оно вообще не освещает ничего, кроме формата записей на диске. Так что разобраться по нему, как работает ZFS - вряд ли возможно. Для этого есть масса интересных блогов и исходники
