> Насколько я понял их описальник - так. Наверное потому они и сгородили какую-то хрень с ZIL (зачем подобие классического журнала нужно в версионнике, строго говоря?) Хинт - какая-то хрень с подобием ZIL есть и в BTRFS. Называется Log Treе. Причина их появления - вами столь любимая производительность. С классическим журналом типа того, что можно найти в extX, ZIL имеет весьма мало общего - в него записываются транзакции (системные вызовы) в высокоуровневых терминах объектов и производимых над ними изменений, которые, в случае сбоя, просто проигрываются через фреймворк VFS так, как будто бы это те же самые системные вызовы. Необходимого размера блоки для него выделяются динамически, для случаев больших операций записи предусмотрена возможность производить запись не в блоки журнала, а напрямую в блок пула, который впоследствии просто влинковывается в дерево блоков во время закрытия группы транзакций. Существенное отличие еще и в том, что ZIL нужен исключительно для повышения производительности, в то время как классический журнал в extX нужен не только для производительности, но и для более быстрой починки после отказа.
И да - есть мнение BTRFS и ZFS таки не версионники, хотя за счет поддержки большого количества снимков вполне могут их в какой-то степени эмулировать.
С одной хренью разобрались, идем дальше.
> метаданные обрабатываюся в том же стиле что и данные. По-моему до БТР так вообще никто не делал (я во всяком случае такого не видел).
Если вы этого не видели, это еще не означает, что этого не существует. Возможно вы просто плохо смотрели. До BTRFS так делал много кто. В ZFS все - и данные, и метаданные, - хранится в объектах, работа с которыми происходит единообразно. Со второй хренью тоже разобрались, идем дальше.
> Суперблок всего лишь некая начальная точка отсчета. Зачем ему вообще CoW делать? Его кто-то постоянно переколбашивает? Он не снабжен резервными копиями?
Вот именно - суперблок это всего лишь начальная точка, корень всего того "леса", который под ним прячется. Соответственно, его потеря равноценна потере доступа ко всем данным в этом "лесу", поскольку, в отличие от extX, положение структур ФС на диске не фиксировано, а догадываться, где именно искать акутальную копию Root Tree на куче немаленьких дисков - развлечение то еще. Да, конечно, предусмотрено до 4 копий (реально на сегодняшний день - до 3, так как петабайтных устройств пока не особо встречается), расположенных в фиксированных местах. Новые версии пишутся поверх старых, то есть ни о каком CoW в применении к суперблокам речи не идет. Но с увеличением количества дисков копий суперблоков становится больше
У ZFS уберблоки (вернее, массивы уберблоков) тоже расположены в фиксированных местах на диске (четыре экземпляра - два в начале и два в конце), но новый уберблок пишется в следующий элемент массива, не трогая старый. В итоге получается своего рода CoW, хотя и в рамках ограниченных областей диска. C увеличением количества дисков количество копий растет - они пишутся на диски, на который производились операции записи в рамках группы транзакций.
Так что в результате получается, что ZFS более CoW, чем BTRFS, вопреки вашему изначальному утверждению. Идем дальше.
> Метаданные оного которые часто меняются (собссно b-деревья) - журналятся по CoW логике в том же духе как и данные.
Все-таки файловые системы, построенные на технике СoW и журнально-структурированные файловые системы - это разные вещи. Да, безусловно, между ними можно усмотреть некоторое сходство, но не более.
Теперь про черт-те-что по пунктам:
> Ну вот ZIL например. Зачем он нужен? По-моему если уж городить версионник, некое подобие классического журнала смотрится каким-то костыльным решением.
С этим уже разобрались и обнаружили аналогичное "костыльное решение" в BTRFS. Будем дальше продолжать называть костыльным подобием классического журнала или?
> Или например в btrfs было заранее предусмотрено изъятие тома из пула, возможность ребалансинга данных между томами после добавления тома,
Ну да, в BTRFS пошли немножко дальше и виртуализировали пространство на отдельных дисковых устройствах в некое линейное пространство, состоящее из областей определенного размера (chunk'ов), что позволило относительно безболезненно производить манипуляции с размером и количеством устройств. Но как и у любой медали, у этого решения есть и обратная сторона - необходимость дополнительного определения конкретного устройства и смещения на нем при доступе. Хорошо это или плохо - как говорится, время покажет. В ZFS без подобного механизма уменьшение размеров или количества устройств реализовать не так то просто - нужно уметь произвольно перемещать блоки, сохраняя все ссылки на них. До сих пор так и нету такого механизма.
> и вообще нечувствительность к месту где хранятся данные - структуры могут лежать где угодно.
C этим тоже разобрались - в обоих случаях структуры данных ФС могут находиться где угодно, включая блоки ZIL и Log Tree. Исключением являются только корневые блоки, находящиеся в определенных местах.
> В итоге катят столь эффектные фокусы как интеграция старой ФС как некий снапшот btrfs-а при конверсии в btrfs. На который даже вернуться можно.
При желании, подобный фокус можно реализовать для любой ФС, в которой не фиксировано положение структур на диске. Вот только это именно фокус - код для его исполнения нужен ровно один раз, однако писать и отлаживать его тем не менее нужно, так как первое впечатление можно произвести только один раз. Является ли отсутствие подобного фокуса "черт знает чем" - думаю нет.
Поскольку далее снова пошли отсылки к статье Вал, можно считать список "черт знает чего" законченным. Что в сухом остатке? Невозможность (на сегодня, а не в принципе) удалять устройства из пула и конвертировать в UFS в ZFS. Ну так это ни для кого не секрет.
> И что? С тех пор дисковые структуры ZFS как-то принципиально изменились? Вы уж извините конечно но ту логику работы которую юзает BTRFS к ZFSным структурам применить не выйдет. Это тот случай про который говорили что "тут всю систему менять надо".
Безусловно, выбор базовых архитектурных решений оказывает существенное и долговременное влияние на развитие любого программного проекта. И естественно, переход, скажем, от блочной организации к экстентной вряд ли может быть простым и безболезненным. Но четкое разделение механизмов и политик позволяет менять последние как будет угодно, меняя и адаптируя поведение системы.
Да и с чего бы, скажите пожалуйста, может вдруг потребоваться все бросить и заняться переделкой блочной структуры в экстентную? Чем экстенты принципиально лучше блоков? Или вы о другом о чем-то?
> Ну как бы кардинально изменить дисковые структуры после выпуска ФС - проблематично
А никто и не говорит о кардинальном изменении дисковых структур. В числе прочего, Вал упоминает метаслабы блоков определенного размера. Так вот это - в чистом виде политика, и от нее на сегодня ничего не осталось, у меня даже не получилось найти ее следов в открытых исходниках, так что толком даже и не посмотришь, как оно когда-то было.
А чуть менее кардинальных изменений было на сегодня уже 25 - по количеству версий дискового формата. Некоторые из них затрагивали формат указателей блоков - начиная использовать поля, ранее зарезервирванные, а это хоть и не кардинальное, но весьма существенное изменение. Конвертации не требуется - вся процедура обновления версии заключается в изменении оной в соответствующем поле уберблока.
> Ну раз вы тут так активно вещаете - вы наверное готовы нам рассказать о крутых изменениях и инновациях, я так вас понимаю? Так расскажите. Куда интереснее чем слюнями брызгать и какашками кидаться.
Кто бы говорил. Мне интересен обмен мнениями, интересные вопросы, а ваши слова про то, как кто-то кому-то что-то подыграл, костыли и подпорки, из которых состоит все, чего нет в линуксе, уже изрядно набили оскомину. Так что предлагаю двигаться в сторону улучшения соотношения сигнал/шум.
> Подсказываю такую ситуацию: юзер подцепляет девайс по юсб к компу. Это же элементарно, Ватсон.
Подсказываете... А разбираться с тем, что там натворил пользователь после этого как прикажете? Так конечно можно сделать, и есть аудитория, которая это непременно оценит :-) Но вот поддерживать такое устройство после того, как там покопается пользователь, может быть весьма проблематично. Это отнюдь не значит, что не надо давать доступа к данным - но для этого не обязательно давать прямой доступ к блоками диска или флэша. Иначе зачем бы люди всякие NAS'ы придумывали. А от необходимости выколупывать данные гораздо лучше спасают регулярные бэкапы, чем гипотетическая возможность что-то выпаять, припаять где-нибудь еще и пробовать замонтировать
