>- надо ли это понимать так, что в ZFS идея CoW
>до финала не доведена, и работа с данными происходит иначе, чем с метаданными. Насколько я понял их описальник - так. Наверное потому они и сгородили какую-то хрень с ZIL (зачем подобие классического журнала нужно в версионнике, строго говоря?) По-моему при создании БТР чуть ли не первыми доперли поюзать для метаданных тот же подход что и для данных, т.е. CoW логику. Как бы в этом плане есть одни довольно существенные грабли: обычные B-деревья (которые хороши для метаданных по скорости), жутко плохо накладываются на CoW логику. При изменении обычного b-дерева много чего меняется и это как бы проблема если хочется применять CoW-логику в этом месте. Потому как будет тормозно и неэффективно. Там архитекту из оракла подыграл посторонний програмер, предложивший свой вариант b-деревьев, хорошо накладывающийся на идею CoW. В итоге получилось довольно забавно - метаданные обрабатываюся в том же стиле что и данные. По-моему до БТР так вообще никто не делал (я во всяком случае такого не видел).
>И да, заодно расскажите нам, как в BTRFS делается CoW для самых
>главных метаданных - суперблока.
Суперблок всего лишь некая начальная точка отсчета. Зачем ему вообще CoW делать? Его кто-то постоянно переколбашивает? Он не снабжен резервными копиями? Или чего? CoW делается для деревьев собссно. Вот они - да, меняются часто а разрушение оных как бы неприятно, т.к. некорректные данные в них запросто ведут к дестою ФС а т.к. они часто меняются - появление там некорректных данных при слете питания и прочая как бы вполне ожидаемо.
>Второй вопрос - с чего вы взяли, что в BTRFS используется журналирование
>данных и метаданных?
С того самого - почитав маны по его архитектуре. Метаданные оного которые часто меняются (собссно b-деревья) - журналятся по CoW логике в том же духе как и данные. По-моему весьма круто придумано.
>Черт знает чего - это чего именно? Можно по пунктам?
Ну вот ZIL например. Зачем он нужен? По-моему если уж городить версионник, некое подобие классического журнала смотрится каким-то костыльным решением. Или например в btrfs было заранее предусмотрено изъятие тома из пула, возможность ребалансинга данных между томами после добавления тома, и вообще нечувствительность к месту где хранятся данные - структуры могут лежать где угодно. В итоге катят столь эффектные фокусы как интеграция старой ФС как некий снапшот btrfs-а при конверсии в btrfs. На который даже вернуться можно. Кстати если что - блондинка в ее статье по костылям ZFS прощлась весьма конкретно и явно лучше чем это смогу я - я ZFS не разрабатывал несколько лет, я лишь некое общее представление заимел о его устройстве. Просто потому что мне нравится изучать всякие технически навернутые сущности :)
>Дак чем именно стройнее и осмысленнее? Не надо к статье отсылать, там
>много устаревшей информации - ибо девушка ушла из Сана в октябре 2004 года и это,
И что? С тех пор дисковые структуры ZFS как-то принципиально изменились? Вы уж извините конечно но ту логику работы которую юзает BTRFS к ZFSным структурам применить не выйдет. Это тот случай про который говорили что "тут всю систему менять надо". В этом плане архитекту оракла прикольно подыграл сторонний разработчик и получилась весьма прикольная и оригинальная конструкция.
>видимо, был последний раз, когда она в код ZFS заглядывала.
Ну как бы кардинально изменить дисковые структуры после выпуска ФС - проблематично, т.к. по сути это будет тотально новая ФС, потребуется полная конверсия в эту ФС старой ФС, совместимость будет убита напрочь и все такое. Не говоря о том что отладку и тестирование придется делать для новой логики заново (а это траходром минимум на несколько лет для сложной ФС). В БТР кстати позволили себе одно изменение структур рушащее совместимость для повышения производительности - они смогли себе позводить это разок, пока их ФС еще никто не юзает в продакшне :).Потом, ессно, такое будет весьма проблематично.
>Посмотреть или спросить кого, не изменилось ли чего с тех времен,
>она для написания статьи не удосужилась.
Ну раз вы тут так активно вещаете - вы наверное готовы нам рассказать о крутых изменениях и инновациях, я так вас понимаю? Так расскажите. Куда интереснее чем слюнями брызгать и какашками кидаться. С удовольствием послушаю. Велкам!
>В мелких девайсах высокая производительность - далеко не самое главное требование. И
>товарищи из MeeGo это понимают, по всей видимости.
В мелких девайсах хочется поиметь некислую надежность без просирака в производительности. Потому что если надежность будет плохой, юзеры понесут девайсы в гарантийку и это попадос. А если девайс будет тормозить - это плохая репутация и тоже попадос.
>но мне сложно представить ситуацию, в которой конечному пользователю мобильного
>устройства может потребоваться прямой доступ к его внутренней файловой системе.
Подсказываю такую ситуацию: юзер подцепляет девайс по юсб к компу. Это же элементарно, Ватсон. Ну или накрайняк - backup & data recovery. Если ФС более-менее стандартная, выколупать из нее данные в случае чего сняв образ (в клиническом случае - программатором например) и замаунтив его на писюке - вполне реалистично.
