>Хинт - какая-то хрень с подобием 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 - когда девайс полностью угробился (искупали например) а данные с него ну просто трындец как нужны и народ на все готов, лишь бы их оттуда достать. В этом случае ФС которой нет на десктопных осях - как нож в спину будет. Ну достали вы эту ФС, а дальше - что? :)
