В мобильной платформе MeeGo (http://www.opennet.me/opennews/art.shtml?num=26050), появившейся в результате объединения проектов Maemo и Moblin, решено (http://lists.meego.com/pipermail/meego-dev/2010-May/002133.html) задействовать по умолчанию файловую систему Btrfs. В качестве основного мотива выбора Btrfs называются расширенные возможности данной ФС в плане сохранения целостности данных: возможность определения и автовосстановления ошибок, за счет поддержки двойного резервирования мета-данных, хранения контрольных сумм и работе с данными и метаданными в режиме copy-on-write (транзакционная файловая система, в которой данные не перезаписываются).
Из других интересных с точки зрения разработчиков мобильной платформы возможностей называются:
- Встроенная поддержка хранения данных в сжатом виде;
- Поддержка доступных на запись снапшотов, которые можно использовать для фоновой автоматической установки обновлений, с последующим мгновенным переключением в обновленное окружение ...URL: http://lists.meego.com/pipermail/meego-dev/2010-May/002133.html
Новость: http://www.opennet.me/opennews/art.shtml?num=26559
Не рановато-ли выводить в продакш, когда оно ещё не стэйбл (афаик) в линукс ядре, т.е. потенциально могут измениться структуры в новых версиях...? Если я прав, то МиГовцы -- это будет полигон для тестов бтрфс.... 8-( Лично я очень интересуюсь развитием бтрфс, но, имхо, нужно было бы использовать более mature решение, вроде ext-fs.
Оригинально. Но в принципе я вполне могу себе представить BTRFS в этом качестве.
а до памяти оно не жруче как zfs? с него же кальку делали..
будет повод добавить оперативки в мобильник
не делали с него кальку.
вот в чем парадокс то.
> а до памяти оно не жруче как zfs?Врядли. ZFS просто как-то странно сделан, так что без жирнючего буффера в оперативе становится тормознутым. Бутер с его дизайном скорее всего куда менее критичен к наличию невъ....нных дисковых буфферов.
> с него же кальку делали..
С дуба рухнули? Оно если и калька то только по некоторым фичам. По внутреннему устройству - более другая ФС, при том имхо намного более удачная по решениям принятым насчет струтур ФС.
> По внутреннему устройству - более другая ФС, при том имхо намного более удачная по решениям принятым насчет струтур ФС.Может ты уже обяснишь внятно, по каким именно? А то я тебя спрашивал вопросы, а ты технично на них перестал отвечать
>уже обяснишь внятно, по каким именноСамое __внятное__ http://lwn.net/Articles/342892/ обяснение от _автора (одного из~) ZFS: ""It's a bit like convergent evolution between marsupials and placental mammals - a marsupial mouse and a placental mouse look nearly identical on the outside, but their internal implementations are quite a bit different!""
~~Это примерно как ?сходящаяся эволюция сумчатых и ?живородящих млекопетающих - сумчаая и живородящая мыши выглядят практически одинаково снаружи, но их внутенние реализации взначительной степени отличаются~~
П=повторяю: это самое +<:)) _внятное объяснение.
То есть более внятного объяснения, чем унылая аллюзия к разнице между сумчатыми и пдацентарными, нету?
>То есть более внятного объяснения, чем унылаяКонечно. Тебе уж и так, и эдак -- ответы на твой "один и тот же" вопрос, мол, не здесь, уж и про хомячков рассказали... Щас па-де-де станцуем, а ты всё так же "задорно" будешь долбить в одну точку. Давай, повтори _Вопрос, чтоб мы ничего не упустили, просим:
Сударь, вы виртуал User294 или он ваш? Вопрос был ему, а не вам. У него, кажется, есть свое имхо, которое он высказывает направо и налево. Если бы по ссылке было что-то, рожденное его пером - вопросов бы не было.Статью эту я читал, и могу сказать, что она содержит большое количество устаревшей информации, поэтому доверия тому, что в ней написано, нет. Кроме того, она скорее пытается ответить на вопрос, чем отличаются ZFS и BTRFS, а не чем одна лучше другой.
Если у вас нет доводов, кроме этой статьи, то ради бога - не надо ничего танцевать, просто постойте в сторонке.
>Сударь, вы виртуал User294 или он ваш?О да. Я везде. Big brother is watching you? :)
>Вопрос был ему, а не вам.
КО намекает: форум - это место для ALL.Если вам это не нравится - стен и места для разбега в мире предостаточно.
>того, она скорее пытается ответить на вопрос, чем отличаются ZFS и
>BTRFS, а не чем одна лучше другой.Так я где-то вроде отвечал вроде? Хотя может модераторы убили или я отправить забыл. Лично мне в btrfs понравилось что для журналинга данных и метаданных используется одинаковый подход, при том так - достаточно быстро и стройно. В ZFS понагородили черт знает чего при том в упомянутой статье (это ведь статья той блондинки, где сравнение кишков ФС, так?) это вполне себе упоминается. И собственно эта статья вполне себе доступно показывает что дисковые структуры btrfs спроектированы явно стройнее и осмысленнее. Если это для вас не показатель чем ФС лучше - ну, блин, убейтесь веником. Потому что в ФС ее структуры и логика работы с ними собссно и есть то что определяет свойства ФС в целом. Больше как бы нечему. И да, бтр по своему красив с его записью метаданных в cow-стиле. Оригинальное и изящное решение по журналингу метаданных. Не тормозное и упрощающее операции с снапшотами.
>не надо ничего танцевать, просто постойте в сторонке.
Да, конечно. Удачи вам в прикручивании zfs в мелкие девайсы. Аж два раза. Я с удовольствием посмотрю на потуги выдавить вменяемую производительность из ZFS на мелком девайсе где мало RAM...
>>того, она скорее пытается ответить на вопрос, чем отличаются ZFS и
>>BTRFS, а не чем одна лучше другой.
>
>Так я где-то вроде отвечал вроде? Хотя может модераторы убили или я
>отправить забыл.Не знаю что там - убили или забыл, но имело место следующее утверждение: "В бтр-е идея CoW доведена до логичного финала - в стиле CoW-логики журнялятся как данные, так и метаданные." Соответственно первый вопрос - надо ли это понимать так, что в ZFS идея CoW до финала не доведена, и работа с данными происходит иначе, чем с метаданными.
И да, заодно расскажите нам, как в BTRFS делается CoW для самых главных метаданных - суперблока.
> Лично мне в btrfs понравилось что для журналинга данных
>и метаданных используется одинаковый подход, при том так - достаточно быстро
>и стройно.Второй вопрос - с чего вы взяли, что в BTRFS используется журналирование данных и метаданных?
> В ZFS понагородили черт знает чего
Черт знает чего - это чего именно? Можно по пунктам?
>И собственно эта статья вполне себе
>доступно показывает что дисковые структуры btrfs спроектированы явно стройнее и осмысленнее.Дак чем именно стройнее и осмысленнее? Не надо к статье отсылать, там много устаревшей информации - ибо девушка ушла из Сана в октябре 2004 года и это, видимо, был последний раз, когда она в код ZFS заглядывала. Посмотреть или спросить кого, не изменилось ли чего с тех времен, она для написания статьи не удосужилась.
Своими словами, пожалуйста.
>Да, конечно. Удачи вам в прикручивании zfs в мелкие девайсы. Аж два
>раза. Я с удовольствием посмотрю на потуги выдавить вменяемую производительность из
>ZFS на мелком девайсе где мало RAM...В мелких девайсах высокая производительность - далеко не самое главное требование. И товарищи из MeeGo это понимают, по всей видимости.
Ну и для сведения - в рамках портирования OpenSolaris на ARM была сделана более компактная версия ZFS, так называемая CZFS. Она, конечно, не совместима с ZFS из-за различий (в сторону уменьшения) размеров структур данных, но мне сложно представить ситуацию, в которой конечному пользователю мобильного устройства может потребоваться прямой доступ к его внутренней файловой системе.
>- надо ли это понимать так, что в 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. Если ФС более-менее стандартная, выколупать из нее данные в случае чего сняв образ (в клиническом случае - программатором например) и замаунтив его на писюке - вполне реалистично.
> Насколько я понял их описальник - так. Наверное потому они и сгородили какую-то хрень с 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'ы придумывали. А от необходимости выколупывать данные гораздо лучше спасают регулярные бэкапы, чем гипотетическая возможность что-то выпаять, припаять где-нибудь еще и пробовать замонтировать
>Хинт - какая-то хрень с подобием ZIL есть и в BTRFS. Называется Log Treе.ZIL все-таки напомнил мне обычный журнал по смыслу. Хоть и для других сущностей. Хотя тут вы в чем-то правы - цель существовария упомянутых деревьев чем-то похожа. Но...
>классическим журналом типа того, что можно найти в extX, ZIL имеет
>весьма мало общего - в него записываются транзакции (системные вызовы) в
>высокоуровневых терминах объектов и производимых над ними изменений, которые, в случае
>сбоя, просто проигрываются через фреймворк VFS так, как будто бы это
>те же самые системные вызовы.Доку по кищкам zfs я тоже читал :) к сожалению, механика ZIL там описана крайне лаконично.
>отличие еще и в том, что ZIL нужен исключительно для повышения производительности,
А парни с http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuni... пишут ровно обратное? Что для скорости ZIL можно вырубить, но тогда пеняйте на себя - целостность при крахе, дескать, никто не обещает. Что вроде как выглядит вполне логично. Они великие гонщики или тут где-то нестыковки? И, собственно, а как выглядит рекавери ФС если ZIL-а нету? Или оно при этом в принципе синхронные записи в стиле требуемом POSIX корректно не сможет тогда? oO Вот в бтр - действительно, явно "для скорости" приделано, чтобы разгрузить CoW механику от постоянных дерганий на каждый пук. Можно было и не приделывать но тогда CoW дергался бы намного чаще при некоторых нагрузках. Что ессно не есть хорошо.
>в то время как классический журнал в extX нужен не только для производительности,
>но и для более быстрой починки после отказа.Ну, вообще-то, я не совсем понял откуда берется мысль про производительность? Нельзя ли пояснить? А то вон чуваки с ссылки выше утверждают что ZIL можно отрубить *подняв* производительность, но делать это ни в коем разе не следует т.к. целостность данных страдает. Что до обычных, типа EXT* - там с журналированием сами знаете как. Обычно журналят вообще только метаданные. ФС то конечно в логически-корректном состоянии после краха, но вот то что данные не окажутся полуперезаписанными такой подход не обещает. А полное журналирование - тормозное на запись однако. Понятно почему.
>И да - есть мнение BTRFS и ZFS таки не версионники,
Я так обозвал дизайны способственны хранить множество состояний без больших накладных расходов. Название не совсем корректное, но лучшего как-то не придумалось...
>хотя за счет поддержки большого количества снимков вполне могут их в какой-то
>степени эмулировать.Ну, можно рассмотреть снапшоты как "версии ФС". Это конечно не совсем то, однако более разумного названия объединяющего похожие по поведению дизайны - лично я придумать не смог. Предложите лучше, чтоли? Хочется называть похожие по общей логике сущности каким-то внятным термином.
>Если вы этого не видели, это еще не означает, что этого не
>существует. Возможно вы просто плохо смотрели.Это запросто. ФС устроены достаточно сложно и я вполне могу пролошиться. Вы в вашем праве отвесить пинка в нужную сторону. Если можете это сделать грамотно и без ругани. А не как iZEN-ы там всякие.
>До BTRFS так делал много кто. В ZFS все - и данные, и метаданные, - хранится
>в объектах, работа с которыми происходит единообразно. Со второй хренью тоже
>разобрались, идем дальше.Насчет разобрались - хм... а поясните парочку мест выше?
>Вот именно - суперблок это всего лишь начальная точка, корень всего того
>"леса", который под ним прячется. Соответственно, его потеря равноценна потере доступа
>ко всем данным в этом "лесу",Да, но суперблоки никто особо и не кантует при крейсерской работе ФС. ИМХО CoW или что-то подобное для суперблока выглядело бы оверкиллом.
>а догадываться, где именно искать акутальную копию Root Tree на куче
>немаленьких дисков - развлечение то еще.Стоит только добавить что такая ситуация должна случаться крайне редко.
>то есть ни о каком CoW в применении к суперблокам речи не идет.
Да и фиг бы с ним, а? Вы часто изменяете суперблоки? Если рассматривать вообще все события которые как-то возможны - ну, на хранилище может метеорит упасть, например.
>У ZFS уберблоки (вернее, массивы уберблоков) тоже расположены в фиксированных местах на
>диске (четыре экземпляра - два в начале и два в конце), но новый уберблок пишется в
>следующий элемент массива, не трогая старый. В итоге получается своего рода CoW,
>хотя и в рамках ограниченных областей диска.Это неплохо придумано. Но честно говоря - а смысл этого действа? Дизайн несколько усложняет, а вот шансы на аварию именно при изменении суперблока - порядка шансов попадания метеорита в хранилище, имхо? Или я тут не прав?
>Так что в результате получается, что ZFS более CoW, чем BTRFS, вопреки
>вашему изначальному утверждению. Идем дальше.Скорее, получается что они реализовали в чем-то похожую по смыслу логику но по разному? (ZIL vs деревья). Чем оно "более CoW" я не понял. Хотя-бы потому что не смог себе представить как выглядит рекавери и синхронные записи в ZFS без ZIL но могу себе представить это в BTRFS (да, без упомянутых деревьев чисто на CoW без подпорочек было бы медленно и печально).
>Все-таки файловые системы, построенные на технике СoW и журнально-структурированные
>файловые системы - это разные вещи.Я в курсе. Но их логика работы похожа в одном аспекте. У них не деструктивная запись. В отличие от классических ФС. В итоге я по большому счету разбиваю ФС на два типа - ФС где запись происходит деструктивно и ФС где запись всегда происходит "в сторонку" - недеструктивно. Конкретная реализация недеструктивной записи может ессно меняться.
>Да, безусловно, между ними можно усмотреть некоторое сходство, но не более.
Ну, мою точку зрения видно выше если что. Некоторое сходство - в недеструктивной процедуре записи, которая никогда не происходит в ту же область данных которая уже занята. В идеале то же самое и для метаданных.
>С этим уже разобрались и обнаружили аналогичное "костыльное решение" в BTRFS.
Ну, допустим, на мое имхо мене костыльное и я вижу как бы btrfs мог работать и совсем без него. Как ZFS мог бы работать без ZIL я не допер а чуваки по ссылке выше утверждают что отключка ZIL может вызвать потерю данных.
>Будем дальше продолжать называть костыльным подобием классического журнала или?
Ну, блин, я не виноват что по логике он похож на обычный журнал. Хоть и оперирует несколько иными сущностями, но общая логика - сильно похожа.
>> Или например в btrfs было заранее предусмотрено изъятие тома из пула, возможность
>> ребалансинга данных между томами после добавления тома,
>Ну да, в BTRFS пошли немножко дальше и виртуализировали пространство на отдельных
>дисковых устройствах в некое линейное пространство, состоящее из областей
>определенного размера (chunk'ов), что позволило относительно безболезненно
>производить манипуляции с размером и количеством устройств. Но как и у любой медали,
>у этого решения есть и обратная сторона - необходимость дополнительного
>определения конкретного устройства и смещения на нем при доступе.Да, но я не думаю что это занимает много времени по сравнению с собственно временем IO операций.
>Хорошо это или плохо - как говорится, время покажет.
Я думаю что нормально. А почему нет?
>В ZFS без подобного механизма уменьшение размеров или количества устройств
>реализовать не так то просто - нужно уметь произвольно перемещать
>блоки, сохраняя все ссылки на них. До сих пор так и нету такого механизма.Угу, в итоге насколько мне известно - изъять диск из ZFSного пула весьма проблематично (я знаю аж 1 метод - раздестроить и пересоздать пул, что как-бы геморройно).
>C этим тоже разобрались - в обоих случаях структуры данных ФС могут
>находиться где угодно, включая блоки ZIL и Log Tree. Исключением являются
>только корневые блоки, находящиеся в определенных местах.Ну, если формально - да, конечно. А если реально - btrfs по факту гибче, вы даже сами это признали вроде.
>код для его исполнения нужен ровно один раз, однако писать и
>отлаживать его тем не менее нужно,Да, только по идее код не такой уж и сложный и достаточно полезный.
>так как первое впечатление можно произвести только один раз.
Ну как бы это сказать? Администраторы обычно рулят более чем одним сервером и потому - чем проще переход, тем меньше у них геморроя.
>Является ли отсутствие подобного фокуса "черт знает чем" - думаю нет.
Ну, в общем то - можно конечно и без фичи обойтись, НО жизню админам она упрощает. И вообще чем проще миграция, тем больше тех кто заморочится ей.
>не в принципе) удалять устройства из пула и конвертировать в UFS
>в ZFS. Ну так это ни для кого не секрет.Плюс местами странный дизайн. ИМХО, btrfs очень не зря упирает на b-деревья. Хорошие структуры, достаточно быстрые и удачные.
>Безусловно, выбор базовых архитектурных решений оказывает существенное и долговременное
>влияние на развитие любого программного проекта. И естественно, переход, скажем,
>от блочной организации к экстентной вряд ли может быть простым и безболезненным.Ессно - просто угробится совместимось в ноль и потребуется полная конверсия ФС. Что мягко говоря нетривиально. А методом "разбомбить и заново отстроить" как-бы может и задолбать пользоваться...
>Но четкое разделение механизмов и политик позволяет менять последние
>как будет угодно, меняя и адаптируя поведение системы.Не более чем позволят дисковые структуры и архитектура.
>Да и с чего бы, скажите пожалуйста, может вдруг потребоваться все бросить
>и заняться переделкой блочной структуры в экстентную? Чем экстенты принципиально лучше
>блоков? Или вы о другом о чем-то?Лично мне ФС основанные на экстентах симпатичнее чем ФС основанные на блоках. Хотя в задницу по производительности конечно можно загнать любую ФС, есть ощущение что ФС на экстентах как-то лучше сопротивляются этому.
>осталось, у меня даже не получилось найти ее следов в открытых
>исходниках, так что толком даже и не посмотришь, как оно когда-то было.Хм, а может вы тогда покритиковали бы ее статью, раз уж хорошо разбираетесь? :)
>А чуть менее кардинальных изменений было на сегодня уже 25 - по
>количеству версий дискового формата. Некоторые из них затрагивали формат
>указателей блоков - начиная использовать поля, ранее зарезервирванные, а это хоть и не
>кардинальное, но весьма существенное изменение. Конвертации не требуется - вся процедура
>обновления версии заключается в изменении оной в соответствующем поле уберблока.Ну это то понятно, но принципиально изменить логику работы ФС или структуры на диске после выхода ФС проблематично. По сути потеря совместимости означает выпуск новой ФС :).Ну как EXT4 с их экстентами. Новая ФС, хоть и есть некая обратная совместимость, но, кстати конвертор из традиционного формата в экстенты они кажись так и не осилили и кому оно надо - ручками, ручками. А эффективность работы с экстентами у них вышла здорово выше на мою имху.
>Кто бы говорил. Мне интересен обмен мнениями, интересные вопросы,Вот такая точка зрения мне нравится. Постараюсь быть поконструктивнее.
>которых состоит все, чего нет в линуксе, уже изрядно набили оскомину.
Да, в конечном итоге - постараюсь быть и пообъективнее.
>Так что предлагаю двигаться в сторону улучшения соотношения сигнал/шум.
Мне эта мысль нравится, буду стараться. Интересные обсуждения - лучше чем кидание какашками. Особенно с теми кто в вопросе явно разбирается :)
>Подсказываете... А разбираться с тем, что там натворил пользователь после этого как
>прикажете? Так конечно можно сделать, и есть аудитория, которая это непременно
>оценит :-)Подсказываю еще раз :). Такая логика как ни странно, УЖЕ реализована в нокиевских n8x0 и n900. Когда юзер цепляет по юсб девайс - data сторажи девайса дисмаунтятся в его родной системе и маунтятся к компу. И все довольны и счастливы. И что характерно, все работает. Потому что реализовано с умом (одновременный доступ двух осей к одной фс - исключен).
>Но вот поддерживать такое устройство после того, как там покопается пользователь,
>может быть весьма проблематично.Ну, нокия таким макаром экспортит сторажи девайса ("карты") на комп юзера. Отключая их от основной системы и отдавая их десктопу. Конечно с btrfs такое упрется в то что для виндов нет дров, но в целом - такий сценарий использования ФС существует, валиден и даже реализован в реальных устройствах которые можно повертеть в руках. Если совместимось с оффтопиком пофиг - можно и FAT заменить на иную фс ведь.
>Это отнюдь не значит, что не надо давать доступа к данным - но для этого
>не обязательно давать прямой доступ к блоками диска или флэша.Никто и не говорит что обязательно, однако я пример пример реально существующего в жизни подхода "предсказанного" вами.
>Иначе зачем бы люди всякие NAS'ы придумывали.
Ну как бы это уже другой калибр решений. И там тоже есть разные подходы. Бывает и экспорт блочных устройств по сети, хоть это и на любителя.
>А от необходимости выколупывать данные гораздо лучше спасают регулярные бэкапы,
Да, но регулярный бэкап телефона или иной embeded или подобной сущности -
>чем гипотетическая возможность что-то выпаять, припаять где-нибудь еще и
>пробовать замонтироватьДа можно и без выпайки даже. Выпайка это совсем уж worst case - когда девайс полностью угробился (искупали например) а данные с него ну просто трындец как нужны и народ на все готов, лишь бы их оттуда достать. В этом случае ФС которой нет на десктопных осях - как нож в спину будет. Ну достали вы эту ФС, а дальше - что? :)
А я могу и не могу одновременно. Что будут вендоры вешать на нанд? Тоже бтр? Заявления заявлениями, но скорее всего бтр будет там, где жёсткие диски и ssd, а там где нанд будет ubifs. Можно конечно предположить, что в будущем в смартфоны будут пихать ssd, вместо распайки флешей, но это было бы глупо, нерационально.
Новость как то мало о чем говорит. Главное, чтобы выбор был.
может быть, если сходить по ссылке - новость покажется более информативной?
>Встроенные механизмы для динамического распределения inode и предотвращения >дефрагментации;А зачем дефрагментацию предотвращать?
>А зачем дефрагментацию предотвращать?Перевод плахой
ориг.
* Built in defragmentation - performance feature for things like boot time
пер.
* Впиндюриная дефрагментация - ускоряющая фишка для такой хрени как время загрузки.
9934 root 20 0 0 0 0 R 18.2 0.0 0:03.31 1 [btrfs-delalloc-]
506 root 20 0 0 0 0 S 15.5 0.0 0:09.50 2 [btrfs-delalloc-]
9933 root 20 0 0 0 0 S 14.8 0.0 0:03.07 0 [btrfs-delalloc-]
9929 root 20 0 0 0 0 S 14.5 0.0 0:02.97 0 [btrfs-delalloc-]
511 root 20 0 0 0 0 S 1.7 0.0 0:00.43 0 [btrfs-endio-wri]
9886 root 20 0 9364 732 616 R 16.3 0.0 0:36.08 2 dd if=/dev/zero of=BIGFILEЭто БТР так процессор кушает... 18.2%, 15.5%, 14.8%, 14.5%
Сколько проживёт батарейка на MeeGo?
вот и я задался вопросом: насколько же бтр годна для карманных устройств, где тесты прожорливости.
>Это БТР так процессор кушает... 18.2%, 15.5%, 14.8%, 14.5%
>Сколько проживёт батарейка на MeeGo?так оно еще и камень жрёт... им придется серьезно над ней поработать..
Дело даже не в том, что она проц жрет, а в том, что падает после спящего режима (при выходе из режима гибернизации). На гентушном форуме это рассматривают.В рассылке один удивляется, почему в МеГоу осталась надпись о том, что это экспериментальная фс и пользоваться ей надо на свой страх и риск. Разрабы обещали пофиксить к .35 или выпустить патч для этого дистра :)))
Вообще, до стабильности еще года два работы. Странное решение.
> так оно еще и камень жрёт... им придется серьезно над ней поработать..Она контрольные суммы считает - ей можно.
Вот уж где-где, а на мобильном устройстве целостность данных не уперлась никуда. А батарейка уперлась.
Подсчет контрольных сумм там и отключить можно (это штатная опция).
Сделай
dd if=/dev/zero of=BIGFILE bs=512
dd if=/dev/zero of=BIGFILE bs=1K
dd if=/dev/zero of=BIGFILE bs=4K
dd if=/dev/zero of=BIGFILE bs=64K
И дай посмотреть на разницу :)
>Сделай
>dd if=/dev/zero of=BIGFILE bs=51260%, 50%, 27%, 27%
>dd if=/dev/zero of=BIGFILE bs=1K74% ,42%, 41%, 29%, 22%
>dd if=/dev/zero of=BIGFILE bs=2K37%, 34%, 30%, 30% ...
>dd if=/dev/zero of=BIGFILE bs=4K33%, 32%, 23%, 22%
>dd if=/dev/zero of=BIGFILE bs=64K38%, 27%, 25%, 26%, ....
>И дай посмотреть на разницу :)Ща iozone прогоню.
------
* HDD - WDC WD7500AAKS-00RBA0
* CPU - 2 x 285 Opteron, 4ГбРам
# iozone -a -b ~/btrfs.xls -+u -p -B -e -EX - размер записи,
Y - %, CPU
Цвет линии - размер блока.Write CPU usage: http://i002.radikal.ru/1005/f0/9c017b5f9629.jpg
Read CPU usage http://s51.radikal.ru/i133/1005/ca/4417c7bce387.jpg
>Это БТР так процессор кушает... 18.2%, 15.5%, 14.8%, 14.5%Если бы ты не только каркал но еще и что-то типа nXX0 в руках повертел то знал бы что там запись на диск - очень дорогая и медленная операция. Поэтому расклад сил там будет совершенно иной чем на твоем писюшнике. Там, прости, просто линейно записать большой блок на диск (что для писюка оптимально) может быть хреновее чем сперва сжать его а потом записать в 2 раза меньше. За счет сокращения тормозного и жрущего проц I/O c "диском" в 2 раза. Правда чудеса? Системы бывают разные, с разным балансом между ценой тех или иных операций.
>Сколько проживёт батарейка на MeeGo?
Думаю что много. Для начала, если постоянно записывать на флещ-диск, батарейка всяко не проживет много. Потому что записываемые данные откуда-то должны взяться (камера? сеть? всяко проц нагрузит и энергию выжрет) да и чип флеша в слип не сможет уйти и вообще флеш в режиме записи - хавает довольно прилично.
занятно. если учесть, что btrfs до относительной стабильности еще пару лет, когда же они meego планируют выпустить?
Надеюсь, ext4 все-таки можно будет использовать без бубна....
>Надеюсь, ext4 все-таки можно будет использовать без бубна....Я на своей n900 переделал /home с vfat на ext3 - и что? ни одно стандартное приложение (проигрыватель, картинковьювер) больше не видело моих файлов :(, в терминале всё нормально естесственно. Дак какой нафиг мне btrfs?
>>Надеюсь, ext4 все-таки можно будет использовать без бубна....
>
>Я на своей n900 переделал /home с vfat на ext3 - и
>что? ни одно стандартное приложение (проигрыватель, картинковьювер) больше не видело моих
>файлов :(, в терминале всё нормально естесственно. Дак какой нафиг мне
>btrfs?Не могу подтвердить, или опровергнуть, но /me бы пожалела флэшку нокии от интенсивного сброса журнала...
У меня все прекрасно работает на / и /home с ext2
ext4 без журнала там будет работать?
>ext4 без журнала там будет работать?Если корень на флэшке, думаю, да (при наличии поддержки ext4, под ядро Maemo 4, на сколько я знаю, модуля ext4 еще нет, насчет пятой версии не в курсе, так как у меня N800)
>>ext4 без журнала там будет работать?
>
>Если корень на флэшке, думаю, да (при наличии поддержки ext4, под ядро
>Maemo 4, на сколько я знаю, модуля ext4 еще нет, насчет
>пятой версии не в курсе, так как у меня N800)В 5 версии если обновить ядро есть модуль ext4.
Ну, это правильно. Btrfs, как я и предсказывал, как раз для встраиваемых устройств под Linux. (А больше в Linux нету подходящих ФС для этого).
>Ну, это правильно. Btrfs, как я и предсказывал, как раз для встраиваемых
>устройств под Linux. (А больше в Linux нету подходящих ФС для
>этого).ext4 в какой-то степени оптимизировали под флэш
Флэш с физическим журналированием несовместим.
авторам jffs-ов это расскажешь, ламерье позорное.
чем орать, посмотрели бы, что такое JFFS2. она как раз на принципах ZFS и btrfs сидит -- т.е. журнально-структурированная ФС. в отличие от ext4 и всех классических файловых систем.
> чем орать, посмотрели бы, что такое JFFS2. она как раз на принципах ZFS и btrfs сидит -- т.е. журнально-структурированная ФС. в отличие от ext4 и всех классических файловых систем.Что есть журнально-структурированная ФС и каким боком BTRFS и ZFS являются журнально-структурированными?
btw, пидивикия с вами не согласна:
Journalling Flash File System version 2 or JFFS2 is a log-structured file system for use in flash memory devices.
Btrfs (B-tree file system, pronounced "Butter F S" or "B-tree F S"[2]) is a GPL-licensed copy-on-write file system for Linux
>Что есть журнально-структурированная ФС и каким боком BTRFS и ZFS являются журнально-
>структурированными?По общей их логике работы, блин. У версионников характерная черта - недеструктивная дозапись-перезапись которая производится в отдельное новое место без затрагивания старых данных, за счет чего и возможно содержать несколько версий файла без геморроя, легко откатывать операции и довольно быстрая запись обладающая при этом журналирующими свойствами "условно на халяву" (расплатой является нужда в процедуре сборки мусора/расчистке места). И тут fresco прав что у них это свойство общее. Как минимум для данных - точно. В деталях это может быть сделано по разному но общая логика этих действий - довольно похожа. Правда я не совсем понял что iZEN обозвал физическим журналом. ИМХО, запись в логоподобную структуру не менее физическая чем запись в область журнала.
>btw, пидивикия с вами не согласна:
У фрески на сайте как бы доки лежат по файловым системам, цитировать ему статьи из википедии мягко говоря не умное начинание.
> как бы доки"как бы доки" - это метко сказано.
А что iZEN понимает под физическим журналированием? Что за термин такой левый вообще? oO
>А что iZEN понимает под физическим журналированием? Что за термин такой левый вообще? oOЯ понимаю под этим использование одного и того же носителя для записи метаданных обеспечения транзакций записи данных. Чем больше метаданных, обеспечивающих транзакционную целостность, записывается на флэш, тем быстрее идёт износ ячеек.
В этом контексте, как писал Шварц в своём блоге, ZFS разрабатывалась с учётом как дороговизны флэш-памяти, так и с учётом ограниченного ресурса флэш-ячеек. Именно поэтому ZFS для флэш весьма оптимальна, в отличие от традиционных журналируемых файловых систем. А UFS2 с включенным механизмом Soft Updates — ещё лучше, так как метаданные транзакций практически целиком находятся в памяти и обеспечивают консистентность ФС, переупорядочивая запросы на запись таким образом, чтобы соблюсти принцип правильной очерёдности следования блоков и подтверждения их записи. Физический кэш диска, конечно, обманывает ожидания операционных систем от записи данных практически всегда — особенно это касается журналирующих ФС (в том числе и по этому показателю они малоэффективны), а вот механизм CoW успешно противостоит неопрадавшимся "ожиданиям".
>Я понимаю под этим использование одного и того же носителя для записи
>метаданных обеспечения транзакций записи данных. Чем больше метаданных, обеспечивающих транзакционную целостность, записывается на флэш, тем быстрее идёт износ ячеек.А еще дважды два - четыре. А благородного дона не смущает что в принципе - объем данных сильно больше объема метаданных? И ведь (какое свинство) эти данные оказываются на носителе путем записи. Изнашивая флеш, да :). В классическом варианте журнала плохо то что запись производится два раза. В идеале - в журнал идут и данные и метаданные чтобы "или все или ничего" применилось и к данным и к метаданным. Но это ухайдакает скорость работы ФС ниже плинтуса за счет двойного набора операций с носителем. Обычно идут на компромисс, оставляя журналинг только метаданных а данные ... ну... вот так вот, да. Можно получить и полуперезаписанный файл в принципе.
Кстати по вашей логике - версионные файловые системы (всевозможные их виды) - ничем таким не отличаются от традиционного журнала? А что, метаданные логоподобные (или какие там у кого) структуры - на том же носителе как правило. Даже в специализированный флешовых файловых системах :).Зато классическая ФС с журналом на отдельном девайсе - это что, отличное решение для флеша? ИМХО - какая-то сильно левая классификация.
>В этом контексте, как писал Шварц в своём блоге,
Знаете, вот уж что-что а по опыту визитов на блоги саней - там был пиар. Которому лично я не довряю. Шварцу, знаете ли, продажи толкать надо. Поэтому надеяться на беспристрастность и честное изложение фактов в его лице - наивно.
>ZFS разрабатывалась с учётом как дороговизны флэш-памяти,
Если посмотреть правде в глаза, ZFS разрабатывалась тогда когда флеш никто еще всерьез юзать не собирался. А Шварц скорее всего толкнул красивый спич просто. Что маркетинговые фигуры - любят.
>так и с учётом ограниченного ресурса флэш-ячеек.
И в чем это выражается? В том что версионник сам по себе число записей снижает? :) Ну так btrfs тоже таким свойством обладает, как и любая иная версионная ФС.
>Именно поэтому ZFS для флэш весьма оптимальна,
Чтобы быть ВЕСЬМА оптимальным, надо выравнивать структуры ФС на нативные блоки флеша (erase-блоки и страницы). Чего ессно в ZFS нет. Да и в btrfs тоже. Да и вообще проблематично это для дисков, маскирующих флеш под якобы дисковый носитель с якобы 512-байтными секторами которые якобы можно записывать независимо. Оптимально можно работать с флешом если он напрямую доступен в виде как есть (чтобы можно было наложить геометрию структур на геометрию флеша предсказуемо и удачно). Но операционки ж это не понимают и их ФС для этого не создавали, посему дать прямой и-фейс к флешу производителям ссыкотно (кто ж такие купит?).
>в отличие от традиционных журналируемых файловых систем. А UFS2 с включенным
>механизмом Soft Updates — ещё лучше,Еще лучще - это если структуры ФС и записи в них будут выровнены на блоки флеша. Чтобы минимизировать перезаписи и ускорить их. Но такое осиливают только для отдельных чипов флеша, для "дисков" с контроллером - сами понимаете, физикой флеша занимается контроллер и как там кому было бы удобно записывать - наружу толком не показывается. В итоге единственное что может сделать ФС - избегать протирания одного и того же места, поменьше записывать и оперировать крупными блоками. Ну и юзать команды discard-а блоков (хоть какой-то хинт контроллеру флешатины о том что ФС более не собирается юзать вон те блоки).
>так как метаданные транзакций практически целиком находятся в памяти
КО намекает: данных в ФС намного больше чем метаданных. Но, собссно, в случае версионников - все достаточно неплохо: идея работы версионника не так уж далека от идеи работы контроллера флеша и размазки записей (как вы думаете, с фига ли специализированные ФС для флеша - это нечто типа log structured как правило?).
>и обеспечивают консистентность ФС, переупорядочивая запросы на запись
>таким образом, чтобы соблюсти принцип правильной очерёдности следования
>блоков и подтверждения их записи.Если честно - с учетом того что на "диске" на которые подойтдет сватаемая ФС обычно есть контроллер который в меру дури переколбасит то что вы ему дали в то что по его мнению правильно - да хрен бы его там знает как в итоге окажется оптимальнее. А ничего что логика контроллера может весьма и весьма меняться у разных производителей?
>Физический кэш диска, конечно, обманывает ожидания операционных систем
>от записи данных практически всегдаА источник статистики какой? Право, любопытно. А то по моим наблюдениям данный грабель вообще-то в реалистичных конфигах заборот.
>— особенно это касается журналирующих ФС (в том числе и по этому
>показателю они малоэффективны),Они малоэффективны в основном потому что писать два раза данные (сперва в журнал, потом на диск) - смерти подобно: скорость записи упадет в 2 с фигом раза. Все остальное уже мелочи. Поэтому обычно журналят только метаданные а данные ... ну вы в курсе, да? :)
>а вот механизм CoW успешно противостоит неопрадавшимся "ожиданиям".
Механика CoW просто не гробит данные и не пишет по два раза. Поэтому если не удалось - да и хрен с ним, старые данные никто не трогал же. В итоге скорость записи - на уровне ФС без журнала (запись то - одна). В бтрфс кстати сие верно и для данных и для метаданных как я понимаю. А у саней ... гм, ZIL это по сути журнал. А уж не журналы ли вы только что обругали? Т.е. ваша ругань валидна и для ZFS? :)
>Механика CoW просто не гробит данные и не пишет по два раза.
>Поэтому если не удалось - да и хрен с ним, старые
>данные никто не трогал же. В итоге скорость записи - на
>уровне ФС без журнала (запись то - одна). В бтрфс кстати
>сие верно и для данных и для метаданных как я понимаю.
>А у саней ... гм, ZIL это по сути журнал. А
>уж не журналы ли вы только что обругали? Т.е. ваша ругань
>валидна и для ZFS? :)Кстати, интересно, что ты думаешь про ZIL?
Ведь это логоподобная структура для поддержки механизма CoW в ZFS. ZIL можно располагать вне файловой ситемы на отдельном носителе для повышения быстродействия. ZIL можно отключать совсем, но тогда гарантировать целостность выполненных транзакций никто не сможет, если вдруг отключат питание во время записи данных на носитель.
самое главное забыл - она все также остается конкурентом zfs и на супер-дупер серверах.
зы:
а вот представить zfs на н900 как-то не получается
>самое главное забыл - она все также остается конкурентом zfs и на
>супер-дупер серверах.
>зы:
>а вот представить zfs на н900 как-то не получаетсяИмхо, ее только к следующему лету(а скорее к концу следующей осени) можно будет начинать пробовать использовать, и то не на критичных сервисах.
в данном случае речь не о серверах.
есть подозрение, что разработка бтр ускорится немного в части мобильных применений.
>а вот представить zfs на н900 как-то не получаетсяА btrfs? Видимо это всё планы на будущее, к тому моменту как оно станет стабильным целевые платформы будут имть на борту по 4 гига RAM и проц на 3 гигагерца =)
и все эти ресурсы нужно точно отдать на прокорм фс? :D
зы:
весь этот период (год?) только выглядит таким далеким.
с точки зрения технологий - это всего лишь следующее поколение девайсов.
собственно все новинки этого года уже известны. и нокия тут не на коне. (радует то, что они это понимают. о чем последняя новость о реструктуризации и говорит)
о девайсах будущего сезона уже кое-какая инфа есть - бтр в миго.
а вот инфы о 3гц процов для мобильников и 4гигах озу - нет. так что про оебс на спарках в кормане только Стругацким писать.
> Ну, это правильно. Btrfs, как я и предсказывал, как раз для встраиваемых устройств
> под Linux.А оракль то в курсе? Они эту ФС имхо под свои БД изначально проектили :).Тем не менее, в принципе, если грамотно все обыграть, версионники могут очень неплохо ложиться на флеш, имхо.
> (А больше в Linux нету подходящих ФС для этого).
Да ну, толсто и уныло. А jffs, ubifs, yaffs, squashfs, ... - это у нас чего? Уж не файловые ли системы ориентированные на юзеж в эмбеддед, на флешках прицепленных без контроллера размазываюшего запись? :)
> А jffs, ubifs, yaffs, squashfs, ... - это у нас чего?ФС прошлого поколения с аховой производительностью либо чтения, либо записи.
>ФС прошлого поколения с аховой производительностью либо чтения, либо записи.Да, они с рядом неидеальностей, но во первых, они есть (о чем iZENы ессно не в курсе) а во вторых - в своих нишах они вполне осмысленны. Например JFFS на NOR флехе размером в 8Мб выглядит вполне вменяемо, более того - btrfs там тупо не заработает :) у него минимальный том - гиг с чем-то, чтоли :).Да и как бы контроллеров там нет и всю механику стирания-записи блоков педалит системный процессор. Всякие там jffs накладывают себя вровень по блокам, etc. И еще не факт что btrfs удастся разложить столь же удачно и удобно для флеша. А стирание блока - тормозная и энергожоркая операция, такие операции надо минимизировать. В принципе - я могу себе представить как btrfs покажет непозорные результаты, т.к. логика CoW неплохо ложится на логику флешатины, но специфичный дизайн заточенный под физические особенности флеша там мог бы работать явно лучше.
Ну сказанное касается только jffs и yaffs. Скваш разумеется не касается, ибо это вообще ридонли специализированная файлуха. Ну и это не касается ubifs, потому что не прошлого и потому что совсем не аховая производительность, производительность там напрямую будет зависеть от количества нандов и их скорости.
сорри, про ubifs действительно ничего не читал. сказал, не подумав.
/me всё больше радуется MeeGO
однако, /me всё дольше предчувствует её появление не раньше следующего лета... А там и фс допилят. ^_^
>/me всё больше радуется MeeGO
>однако, /me всё дольше предчувствует её появление не раньше следующего лета... А
>там и фс допилят. ^_^ну, пока нокия выпустит маемо 6 а платформу доведут до ума и получится крутая штука. в интеле и нокии не дураки работают.
Хмммм....
А у меня одного, когда на разделе с btrfs остаётся места меньше 15-20% начинаются жутчайшие тормоза и нет возможности что либо записать, хотя df показывает туеву хучу места?
Представил себе такое на моб. устройстве.
не только у тебя
что для меня остается непонятным в этом союзе интела и нокии, так это то, какие камни будут использоваться в MeeGo девайсах. не уж то атом будут поголовно пихать? если нет, то какой тогда интелу в этом интерес?
Не думается что только атомы. Нокия такая хитрая контора которая дружит сразу с много кем. И врядли нокия будет посылать Ti (делающий ARMы) в обозримом будущем. Просто будут несколько разнокалиберных выводков девайсов с более-менее одинаковой ОС на них. Сделать ОС которая может работать на разных мобильных железках - логично и разумно, разве нет?
да, весьма. просто мне в свое время Wintel покоя не давал.
>что для меня остается непонятным в этом союзе интела и нокии, так
>это то, какие камни будут использоваться в MeeGo девайсах. не уж
>то атом будут поголовно пихать? если нет, то какой тогда интелу
>в этом интерес?Интел разрабатывает новый процессор специально для нокии. Там прямо в камень будут встроены кодеки.
