Представлен (https://db.usenix.org/publications/login/2012-02/) февральский номер электронного журнала ";login:", интерес в котором представляет статья "Btrfs: The Swiss Army Knife of Storage (https://db.usenix.org/publications/login/2012-02/openpdfs/Ba...)", написанная одним из разработчиков файловой системы Btrfs. В статье подробно и доступно рассказано о сегодняшнем состоянии развития Btrfs и наиболее интересных возможностях.URL: https://db.usenix.org/publications/login/2012-02/
Новость: http://www.opennet.me/opennews/art.shtml?num=33048
Прелестно :)
Ждём btrfs в Fedora 17.
И не только там. Хорошая штука будет, 4 года на разработку не прошли даром.
Как раз прошли даром. Поставь себе на десктоп, и поразись небывалым ощущениям от 4 летней разработки.
Я устраиваю регулярные тестовые вылеты на этой штуке - мне она нужна, тудыть-растудыть. Впечатления вполне позитивные. Наверное я что-то делаю не так, но раньше оно тормозило и оопс-ами икало с полоборота. А теперь - just works, однако. Не, наверное какими-то хитрозагнутыми манипуляциями это еще можно навернуть, но при крейсерском режиме оно и довольно шустрое и каких-то нестабильностей я не вижу.
Ты все делаешь не так.На свежеотформотированном разделе она летает как впрочем и 4 года назад. Вопросы начнутся когда начнешь работать с этим разделом каждый день а не по случаю.
Кстати у мена не было ни 1 OOPS за все время почти ежедневного тестирования примерно за 2 года. Наврено повезло, не знаю. Но тормоза...
Работаю каждый день.
Винт 500Гб. Ноут. Всё под бтр и со сжатием lzo. Штук 6 субволумов. Пережил ядра 3.0 - 3.2.5 последовательно.
Недавно отписывался.
Повторять лень.
Доволен.
Зыж
А да. Гента. Всё из сырцов. Мульёны файлов.
> Кстати у мена не было ни 1 OOPS за все время почти ежедневного тестирования примерно
> за 2 года. Наврено повезло, не знаю. Но тормоза...На ранних версиях - очень даже было. Сейчас оно уже починено, разумеется.
Вылеты? А ты попробуй создай раздел, 1.000.000 мелких файлов, запусти bonnie++ в 20 потоков, а потом выруби питание. Вот это будет вылет.
Может сразу молотком по винту?
Хрена мелочиться то?Зыж
Пусть снершот сделает до этого.
И такие троли с идиотскими предложениями ему уже не страшны. В отличии от всех остальных фс.
> И такие троли с идиотскими предложениями ему уже не страшны. В отличии
> от всех остальных фс.Насчет идиотских предложений - не согласен. Отличное и своевременное предложение устроить стресс-тесты по полной, до того как оно в релизах основных дистрах станет дефолтным. Насчет снапшота - бтрфс их делает автоматически и в случае такого факапа должен сам отматывать на ближайший автоматический снапшот. И как вы понимаете, в наших же интересах проверить что у нас катапульта работает на тестовых манекенах во всех ситувциях, до того как она облажается спасти тушки наших настоящих ценных данных.
>Насчет идиотских предложений - не согласен. Отличное и своевременное предложение устроить стресс-тесты по полной,в таких "тестах": - xfs сдохнет >99.9% - ntfs сдохнет >50% - ext4 сдохнет <30%
и тд.
и что интересно - это не делает эти фс плохими.
не вижу смысла пополнять этим мусором ещё одной фс, тем более что результат в общем предсказуем (если что - на уровне ntfs).единственное что интересует - можно ли (и как быстро) после такого "тестирования" восстановить систему в валидном состоянии.
и тут как раз у бтр преимущество более чем очевидное.
> Насчет снапшота - бтрфс их делает автоматическиу меня это делает cron-скрипт в 5 строчек.
при этом в grub усть запись - lastsnapshot
А ZFS v.28?
> А ZFS v.28?Судя по лисяре она радостно сдувается на паре бэдов. Нас так не устроит, извините.
> в таких "тестах": - xfs сдохнет >99.9% - ntfs сдохнет >50% - ext4 сдохнет <30%CoW механика такое должна пережить. Знаете в чем фундаментальное отличие? У всех перечисленных запись - деструктивная. Полное журналирование данных они не делают.
А вот btrfs от такого дохнуть не должно. Таков ее дизайн - недеструктивная запись в сторонку. Если это не работает ... стоп, а на кой хрен нам самих себя дурить? Нам же это и юзать потом. Поэтому идея протестировать во всех ситуациях, включая максимально десткие - отличная. А скажите, намного лучше если у вас рассыпется ТЕСТОВЫЙ набор данных, а настоящий зато потом переживет это, а?!
> у меня это делает cron-скрипт в 5 строчек.Ну это вы видимо про постоянные снапшоты. А я про временные, которые существуют только некоторое время а потом прибиваются. Такие раз в 30 секунд сами лепятся и в случае факапа ФС просто откатывается на прошлый удачный - вот и все "рекавери от краха" (по идее теряется только то что было недописано в последние 30 секунд).
И кстати как вы с постоянными снапшотами решаете вопрос с местом на диске? Они же место жрут, потому что отличия от прощлого снапшота неизбежно надо хранить. Вы как-то расчищаете старье?
Готов провести любые тесты и поделиться результатами. Пишите, что делать и в какой последовательности.
Я как-то пробовал. По-моему в убунту. После обновления перестал загружаться - поддержку из ядра выкинули :) Пока не рискую.
Убунту в своём репертуаре.
> Убунту в своём репертуаре.Я уж не знаю что он там сделал, но в убунте поддержка btrfs - с незапамятных времен. И никто ее оттуда не выкидывал. Dmesg нужен или поверите на слово?
> Я уж не знаю что он там сделал, но в убунте поддержка btrfs - с незапамятных времен.Ее там лично разработчики Canonical делали?
> Ее там лично разработчики Canonical делали?Нет, конечно. Начальный дизайн делал лично Крис Мэйсон из оракла, как ни странно. Тем не менее поскольку оно в майнлайне то оттуда досталось всем современным дистрам. В общем то единственным моментом я бы отметил что пользоваться оной более-менее всерьез имеет смысл начинать с ядер 3.2...3.3 примерно. Там было довольно много изменений и более старые версии - ну их нафиг. Убунты с достаточно свежим ядром по дефолту - еще не вышло. А с более старым - все-таки потенциально на свой окорок, так, глядя на объем багфиксинга и изменений.
стоит убунта 11.10 с ядром 3.0.0-16. единственное сделал раздел с ext4 для boot, на остальных brtfs. Нормально работает, стабильно, скорость устраивает
> стоит убунта 11.10 с ядром 3.0.0-16. единственное сделал раздел с ext4 для
> boot, на остальных brtfs. Нормально работает, стабильно, скорость устраиваетДа, в принципе - работает. Я уж не знаю что вон те кудесники которые выше сделали чтобы это отломать. Но вообще, в 3.2 вкатили довольно много изменений и фиксов и потому лично я как-то предпочитаю рассматривать 3.2 как необходимый минимум. Это возможно является перестраховкой, однако в таких вопросах как ФС лучше перебдеть чем потом разбирать макароны с нужного тома с нужными данными.
> Я уж не знаю что он там сделал, но в убунте поддержка
> btrfs - с незапамятных времен. И никто ее оттуда не выкидывал.Зачем выкидывать, если можно сломать?
> Зачем выкидывать, если можно сломать?Скорее, не починить. Убунты с кернелом 3.2 или новее еще не вышло, а там бтр-а серьезно подтянули. На более древних ядрах я бы пожалуй постеснялся ее юзать как ФС под систему или типа того.
Не знаю, что ты там пробовал, а я сидел на btrfs больше года, с момента покупки ssd, и всё пучком. Т.е. с 10.10 версии. Один раз лишь система стала небутовой - это мои руки виноваты, которые полезли в 11.10 врубать новомодную LZO компрессию для корня, не проверив наличие её поддержки у grub'а в стоковом состоянии.
> Не знаю, что ты там пробовал, а я сидел на btrfs больше
> года, с момента покупки ssd, и всё пучком. Т.е. с 10.10
> версии. Один раз лишь система стала небутовой - это мои руки
> виноваты, которые полезли в 11.10 врубать новомодную LZO компрессию для корня,
> не проверив наличие её поддержки у grub'а в стоковом состоянии.На SSSD и FAT будет летать пучком. Речь про плохую производительность с обычными дисками. Ну а про то что делать админам малых офисов где копейки считают когда накроется пару секторов (fsck "вот вот появится" года 2, последние новости - "со дня на день".) лучше помолчать.
Нормальная производительность.
Не хуже екст4.
Недавно отписывался в теме по презентахе.
Лень повторять. Поэтому скажу проще — вы не правы.
> На SSSD и FAT будет летать пучком.Не будет: нет индекса директорий, а разгребать линейные списки в поисках файла, если файлов много - весьма опаньки. JFYI, фат жесточайше тормозит на дирах с большим числом файлов. По этому поводу многие программы с файловыми кешами вынуждены размазывать их на разлапистые структуры директорий. Потому что дефективные ФС плохо работают когда в 1 дире тысячи файлов.
> Речь про плохую производительность с обычными дисками.
Нормальная она там вполне, не хуже многих других. Единственный случай откровенного слива который мне известен - sqlite, из-за того что логика его журнала дурно накладывается на логику btrfs и получается двойная работа.
> Ну а про то что делать админам малых офисов где копейки считают когда накроется
> пару секторов (fsck "вот вот появится" года 2, последние новости - "со дня на день".)
> лучше помолчать.Ну так это, у некоторых других на таком же пепелаце такой утили нет, не обещают и не собираются вообще. И что, по вашему это лучше?!
> Не будет: нет индекса директорий, а разгребать линейные списки в поисках файла,
> если файлов много - весьма опаньки. JFYI, фат жесточайше тормозит на
> дирах с большим числом файлов. По этому поводу многие программы с
> файловыми кешами вынуждены размазывать их на разлапистые структуры директорий.Свалка миллиона файлов в одну диру - не правильное решение by design. Если у вас настолько кривые руки/писульки, то не нужно их так халатно покрывать.
> Свалка миллиона файлов в одну диру - не правильное решение by design.Нет, чувак, хорошая файловая система не должна испытывать проблем от миллиона файлов в 1 дире. Потому что случаи разные бывают.
А вот размазывание по куче дир/субдир кешей и прочая на уровне приложений - это как раз галимый костыль, спровоцированный тем что дерьмовые ФС не выполняют своих прямых обязанностей.
По той же логике если базу данных не удается сделать более чем 100 000 записей и чтоб работало быстро, проги должны сами по достижении 100 000 записей новые БД создавать :)
> Если у вас настолько кривые руки/писульки, то не нужно их так халатно покрывать.
Кривые писульки - у тех у кого ФС тормозит от миллиона файлов в 1 дире. Это root cause. Остальное лишь сугубо костыли по устранению этого дефекта.
fsck наконец начал потихоньку появляться. У криса в ветке со страшным названием.
Надо было придержать материал до Масленицы :)
> Надо было придержать материал до Масленицы :)До вторжения инопланетян, чего уж там.
У меня сейчас Fedora 16 стоит целиом на btrfs всё работает как часы, если прописать правельные mount options она начинает работать со страшной скоростью ^^)
правильные это какие ?
/ defaults,compress=lzo,noacl,noatime,nodatasum,notreelog,inode_cache,space_cache/boot defaults,noacl,noatime,nodatasum,notreelog,inode_cache,space_cache
DO NOT enable compression on /boot partition!!!
А разве grub умеет грузиться с btrfs? Или используете какой-то другой загрузчик?
Grub2 Умеет
Нут так можно раздел ext2 на 100 Мб под boot выделить, грузится без проблем с чего угодно (имеется ввиду /).
noacl,nodatasum,notreelog - а нагуя тебе тогда btrfs?
nobtrfs
Меня интересует скорость работы, а не запись мегатонных метаданных, притом что файловая система спокойно переживала не однократный hard reset и прекрасно продолжает работать
> Меня интересует скорость работы, а не запись мегатонных метаданных, притом что файловая
> система спокойно переживала не однократный hard reset и прекрасно продолжает работатьМожет, проще все-таки ext2 или FAT16?
> Может, проще все-таки ext2 или FAT16?У них скорость работы конечно обалденна, да :)
> Меня интересует скорость работы, а не запись мегатонных метаданных, притом что файловая
> система спокойно переживала не однократный hard reset и прекрасно продолжает работатьZFS? :) 6 лет в продакшене.
> ZFS? :) 6 лет в продакшене.Не будет ее в линухе. Солярис - закрыт ораклом и предоставляется на геморных условиях. *бсд и продакшн - довольно любопытное сочетание если в списки рассылки посмотреть. Там красивый такой "ынтырпрайз" царит, что я пожалуй обойдусь, пусть изены такие ынтырпрайзы на своих 3 ноутовых дисках юзают :)
> ZFS? :)Про скорость удачная шутка. Хотя если буфер гига на 64 - может и ничего, конечно. Правда, рамдиск без ZFS - вообще реактивная штука.
> Правда, рамдиск без ZFS - вообще реактивная штука.И, заметим без иронии, столь же устойчивая к хард-резету. Но это не потому, что рамдиск такой надежный, а потому что ZFS ненадежная.
> И, заметим без иронии,, ..., ..., без FSCK, однако. Поэтому когда этот крутой энтерпрайзный пепелац на эн терабайтов заедет в канаву из-за пары внезапно вылезших на диске бэдов (которых теоретически быть как бы не должно) и как-то так окажется что бэкапов вот ну нет блин и все тут - вы рискуете повторить приключения господина с Лиссяры, устраивавшего закат солнца вручную, только еще не факт что так легко отделаетесь. Потому что полноценной тулзы оффлайнового восстановления ФС нет и видимо не будет. А вот у некоторых такое очень даже будет.
> Потому что полноценной тулзы оффлайнового восстановления ФС нет и видимо не будет. А вот у некоторых такое очень даже будет.zpool import -F poolname ; zpool scrub poolname
там какбЭ бедблоки упоминалсь, а не манипуляции с предыдущими валидными состояниями системы.
в общем - не к месту.
> там какбЭ бедблоки упоминалсь, а не манипуляции с предыдущими валидными состояниями системы.Научитесь читать ВСЁ сообщение, а не пропускать остальное.
"вы рискуете повторить приключения господина с Лиссяры, устраивавшего закат солнца вручную, только еще не факт что так легко отделаетесь."
Предмет разговора: http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../
— восстановление убитого (FAULTED) пула "подручными средствами", которые на тот момент (2011-02-04) было доступно. А именно, восстановление пула методом ручного отката к последней успешной транзакции записи на него, до того момента, когда пул окончательно развалился.
Оказалось, что один из дисков пула покрыт бэдами. Недолго думая, да и пул уже развалился, автор решил ВРУЧНУЮ скопировать данные с глючащего диска на новый такой же, ОБХОДЯ_СБОЙНЫЕ_СЕКТОРА. Понятно, что пул новый диск не признал.Если внимательно прочитать статью о закате солнца вручную, то мы увидим, что автор мучался с откатом к последней удачной транзакции (uberblock с позицией 92 в списке) на пуле. Вручную ему удалось записать несколько байтов в участок с метаинформацией о завершённых транзакциях.
Год спустя.
"После обновления, в правке за номером 219089 [3], ZFS до версии 28, в zpool(8) появилась возможность откатываться на несколько транзакций назад при передаче параметра -F. Так что описанный в статье приём восстановления стал обычной рутинной задачей."
Занавес.
> Потому что полноценной тулзы оффлайнового восстановления ФС нет и видимо не будет. А вот у некоторых такое очень даже будет.
zpool import -F poolname — попытка импортирования пула с последней неповреждённой транзакцией.
zpool scrub poolname — верификация данных и метаданных, восстановление повреждений данных, вывод списка необратимо повреждённых файлов.
> в общем - не к месту.В общем, кто бы говорил.
> — восстановление убитого (FAULTED) пула "подручными средствами", которые на тот
> момент (2011-02-04) было доступно. А именно, восстановление пула методом ручного отката
> к последней успешной транзакции записи на него, до того момента, когда
> пул окончательно развалился.Как бы тебе объяснить то? Скажи, а ты отдаешь себе отчет в том что в общем случае транзакции вообще не обязаны например быть последними? А откат на полгода назад (если конечно такой снапшот был) тебя я думаю сильно не обрадует. Если это вообще возможно.
> Если внимательно прочитать статью о закате солнца вручную, то мы увидим,
...что средств рекавери у ZFS с гулькин нос. Да, конкретно эту ситуацию аж пролечили,
> Год спустя.
> параметра -F. Так что описанный в статье приём восстановления стал обычной
> рутинной задачей."
> Занавес.Занавес тут только по одному поводу: один клоун упорно не понимает что вон то лечение - катит только в сильно некоторой ситуации и с факапом должно как-то так очень ювелирно повезти чтобы он случился именно вот так, а не как-то иначе.
А вот про то чего делать в случае если факап случится по другому - маркетологи и изены не говорят. А вот перспектива парсить такую монстрилку лично в хексэдиторе как-то душу ну совсем не согревает.
>> — восстановление убитого (FAULTED) пула "подручными средствами", которые на тот
>> момент (2011-02-04) было доступно. А именно, восстановление пула методом ручного отката
>> к последней успешной транзакции записи на него, до того момента, когда
>> пул окончательно развалился.
> Как бы тебе объяснить то? Скажи, а ты отдаешь себе отчет в
> том что в общем случае транзакции вообще не обязаны например быть
> последними?Список последних транзакций либо хранится, либо не хранится. На ZFS такой список хранится.
> А откат на полгода назад (если конечно такой снапшот был)
> тебя я думаю сильно не обрадует. Если это вообще возможно.Транзакции — не снапшоты.
>> Если внимательно прочитать статью о закате солнца вручную, то мы увидим,
> ...что средств рекавери у ZFS с гулькин нос.У Btrfs ещё нет стабильной fsck. О каком восстановлении линуксовой ФС сейчас может идти речь?
ZFS сохраняет состояние непротиворечивым в силу особенностей CoW и собственной архитектуры. Противоречивое состояние на разрушенном (FAULTED) пуле можно отмотать назад и тем самым его восстановить. Никто ничего не обещает, если накрылся Stripe-массив, но если все диски оказались живы, то почему не попробовать отмотать состояние?> Занавес тут только по одному поводу: один клоун упорно не понимает что
> вон то лечение - катит только в сильно некоторой ситуацииНикакое лечение не катит, если из страп-пула или другого неотказоустойчивого пула выпал — размагнитили, стёрли, сгорел, потеряли, разбили — хоть один носитель. Других примеров я не знаю.
> и
> с факапом должно как-то так очень ювелирно повезти чтобы он случился
> именно вот так, а не как-то иначе.Чего?
> А вот про то чего делать в случае если факап случится по
> другому - маркетологи и изены не говорят. А вот перспектива парсить
> такую монстрилку лично в хексэдиторе как-то душу ну совсем не согревает.
>> ZFS? :)
> Про скорость удачная шутка. Хотя если буфер гига на 64 - может
> и ничего, конечно. Правда, рамдиск без ZFS - вообще реактивная штука.Вы хотите поговорить о скорости? Давайте, можно ли сделать у вас таким образом:
делаете зеркало (пятерку, шестерку, десятку - по вкусу) + добавляете ссд винтов, общей размерности с получившийся раздел или несколько меньше, и запихиваете их в l2arc кеш. В результате получаете: на основной массив идет только запись, а чтение идет с ссд дисков. ссд протирается? да без проблем, данные у нас все равно на обычных носителях, выкинули протертый винт, вставили на его место другой.
> выкинули протертый винт, вставили на его место другой.Ну да, если вы можете позволить себе менять мерседес по мере заполнения пепельницы - отличный вариант :)
>> выкинули протертый винт, вставили на его место другой.
> Ну да, если вы можете позволить себе менять мерседес по мере заполнения
> пепельницы - отличный вариант :)ссд сейчас стоят не так дорого, а если нужно увеличивать производительность не теряя надежности - см. мой ответ.
Performance Improvement of Btrfs
https://events.linuxfoundation.org/slides/2011/linuxcon-japa...
> / defaults,compress=lzo,noacl,noatime,nodatasum,notreelog,inode_cache,space_cacheГм, nodatasum,notreelog как-то не очень прикольно выглядит.
Останется удалить журнал, и вот она, рыба моей мечты - FAT!!!
> Останется удалить журнал, и вот она, рыба моей мечты - FAT!!!Ты забыл лицензию M$. Хау мач из зе фиш, бабка? :D:D:D
> Останется удалить журнал,Угу. Вот ща я оторву у космолета колеса...
> и вот она, рыба моей мечты - FAT!!!
...и он превратится в запорожец!!!
Стоп, что за фигня? У космолета оказывается колес нету. Отрывать нечего. FAIL!
Хм... nodatasum?!!
>правильные это какие ?-t ext4
> -t ext4Какой "правильный мерседес" марки "простенький мотороллер" :)
Скажите пож Ваше мнение насчет названия -";login:", вроде как ";" - строка, а символ - означает завершения оператора, по таблице аски -он не подходит к св-ву символьного представления информации в машине (если цифра, то цифра -'0' - получим цифру, так как последовательность не прирывается и по умолчанию тип int),,, что означает этот символ -это просто метафора 16-летних???? скрывает нестандартное мышление????? Просто интересно с точки зрения программирования. Спасибо!
Всё же написано у них на сайте http://www.usenix.org/publications/login/whysemi.html"The ; was utilitarian. During most of the early '70s the most popular terminal was the Teletype model 37. The sequence <esc>; put it into full-duplex mode so the terminal didn't print characters locally, but let the system echo them. So this sequence was put into the greeting message. Of course it didn't print when you used that terminal, but other terminals that appeared later didn't understand the message and so printed the ;."
Peter H. Salus, A Quarter Century of UNIX, page 69.
Эти статьи и лекции о баттере уже утомлять начинают одно и то же пережевывать. Лучше бы написали когда дедупликацию ждать и стоит ли вообще.
Патчи есть, над этим работают.Кроме того, работают и над тем, что б снимки не портили cow-копии.
Я думаю, всё это будет.
Я фигню сказал. Хотел сказать про дефрагментацию, которая не ломает cow-копии.
Кно-нибудь, кроме автора новости, подписан на этот журнал? И вообще на Usenix?
Всё, ссылки сдохли, теперь только платно.