Объявлено (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/13936) о возрождении Git-репозитория на kernel.org с набором утилит btrfs-progs, ориентированных на управление разделами с файловой системой Btrfs. В отличие от ранее доступного пакета btrfs-progs, в новой версии появилась поддержка режима "scrub", при котором осуществляется чтение и проверка всех данных и метаданных с целью выявления ошибок и нарушений целостности в файловой системе Btrfs.
Загрузить новую стабильную версию утилит можно из репозитория git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git. Для сборки требуется наличие библиотек libuuid и libattr (в Debian находятся в пакетах uuid-dev и libattr-dev, в Fedora - libuuid.devel и libattr-deve).
Дополнительно отмечается ответвление (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/13988) новой экспериментальной ветки, в которой добавлены утилиты qgroups и restriper, а также утилита recovery для извелечения файлов с повреждённой ...URL: http://www.h-online.com/open/news/item/New-release-of-the-Bt...
Новость: http://www.opennet.me/opennews/art.shtml?num=32191
Отлично! Просто отлично! C ужасом жду выхода и результатов проверки своих разделов ~1.5 годичной давности
Проверить (и убедиться в наличии каких-то мелких косячков) можно уже с пол года как, только исправлять пока оно не берётся :) Так что ждать надо с радостью, а не ужасом! ;)
Хм, что значит - не берутся? А что же тогда за пачки исправлений в ченжлогах ядра? Или починенный баг за баг не считается? :)
Речь об исправлении ошибок в вашей файловой системе, а не в коде ядра.
Вот так-то!
Дык разговор еще только идет о выпуске бета-версии fsck. И чего вы ожидали? Кстати у ZFSных камикадзей fsck вообще нету а как они исправляют ошибки - можно на лисяре почитать, там хардкор с ручным редактированием структур файловой системы вообще ;)
> Дык разговор еще только идет о выпуске бета-версии fsck. И чего вы
> ожидали? Кстати у ZFSных камикадзей fsck вообще нету а как они
> исправляют ошибки - можно на лисяре почитать, там хардкор с ручным
> редактированием структур файловой системы вообще ;)В ZFSv28 (теперь это мейнстрим на FreeBSD) возможно восстановление структуры ФС без редактирования в HEX-редакторе содержимого дисков — достаточно одной команды: "zpool import -F poolname". Производится поиск последних завершённых групп транзакций и восстановления состояния непротиворечивости по ним.
Пример:
% zpool export space
% zpool import -F space
Pool space returned to its state as of вторник, 1 ноября 2011 г. 22:48:55.
% uname -rsm
FreeBSD 9.0-RC1 amd64
Разницы в скорости импортирования с ключом "-F" и без на неповреждённом пуле не заметил.
Чтобы больше не попадать впросак с заявлениями о невозможности восстановления ZFS или необходимости в ручном редактировании структур файловой системы, необходимо хотя бы иногда читать новости о процессе разработки: http://www.opennet.me/opennews/art.shtml?num=30797И, да, у ZFSных камикадзей есть man zpool: http://www.freebsd.org/cgi/man.cgi?query=zpool&apropos=0&sek...
В котором описана волшебная команда zpool scrub pool...
> import -F poolname". Производится поиск последних завершённых групп транзакций и восстановления
> состояния непротиворечивости по ним.Ну так это заткнули для одной конкретной ситуации, видимо похожей на то что недавно в списке рассылки btrfs было. А полноценного fsck - нету.
> Разницы в скорости импортирования с ключом "-F" и без на неповреждённом пуле
> не заметил.В случае починки основательно разваленной ФС волновать будет не скорость. Программно - всяко быстрее чем ручками файлы доставать, вручную парся структуры с калькулятором и хексредактором, потому что сама ФС видите ли облажалась и выпала в немоунтабельное состояние или состояние при котором драйвер с грохотом валится.
> Чтобы больше не попадать впросак с заявлениями о невозможности восстановления ZFS или
> необходимости в ручном редактировании структур файловой системы,Гораздо интереснее было бы посмотреть на твою мину при восстановлении всерьез рассыпавшегося пула, когда драйвер не сможет это подхватить, а полноценных утилей восстановления как бы и нету толком.
> И, да, у ZFSных камикадзей есть man zpool:
> В котором описана волшебная команда zpool scrub pool...А толку? Это не есть полный аналог fsck.
> В случае починки основательно разваленной ФС волновать будет не скорость. Программно -
> всяко быстрее чем ручками файлы доставать, вручную парся структуры с калькулятором
> и хексредактором, потому что сама ФС видите ли облажалась и выпала
> в немоунтабельное состояние или состояние при котором драйвер с грохотом валится.Свежий случай на системном пуле, заполненном на 99% от полезной ёмкости:
не найден загрузочный пул ("can't find boot pool", и при попытке загрузки вываливается приглашение загрузчика). Сам пул импортируется/экспортируется обычным образом в ОС с диска восстановления, файлы целы, scrub после многочасовой проверки показывает отсутствие ошибок.>> Чтобы больше не попадать впросак с заявлениями о невозможности восстановления ZFS или
>> необходимости в ручном редактировании структур файловой системы,
> Гораздо интереснее было бы посмотреть на твою мину при восстановлении всерьез рассыпавшегося
> пула, когда драйвер не сможет это подхватить, а полноценных утилей восстановления
> как бы и нету толком.Ты всерьёз полагаешь, что я огорчусь от рассыпавшегося пула? Я тебя огорчу: у меня есть бэкапы и резервирование важных данных.
>> И, да, у ZFSных камикадзей есть man zpool:
>> В котором описана волшебная команда zpool scrub pool...
> А толку? Это не есть полный аналог fsck.А толку от fsck?!
У нас хотя бы есть scrub, который чинит, если есть возможность, саму ФС и файлы на ней, и показывает в выхлопе список всех повреждённых, невозможных к починке файлов с полными путями к ним. А ваш fsck складывает найденные цепочки блоков в безымянные файлы в каталог lost+found — разбирайтесь сами, что там такое и нужно ли вам оно. :))
Для btrfs тоже есть scrub.
>У нас хотя бы есть scrubа у нас его типа нету?
>>У нас хотя бы есть scrub
> а у нас его типа нету?У вас? У вас scrub ничего не исправляет.
Омг... а я как-то и не заморачивался с восстановлением, думал оно есть... уже не стал вникать в суть, но опытным путём обнаружил, что помогала перестановка загрузчика(на /boot был не btrfs).
Я, конечно, попытаюсь погуглить на досуге, но подскажите, пожалуйста: как это работало!?
Неужели, таблицы ФС связаны с загрузчиком?
К сожалению подтверждаются мои худшие подозрения: Оракл мутит с btrfs что то нехорошее. Под F16-RC2 тормозища неописуемые при fsync. Короче народ, даже не думайте, ставьте только ext4, xfs и прочее провереное. Не вышел каменный цветок. А как дысал, как дысал...
Вспоминая интервью Шишкина где он рассказал как этот Btrfs устроен не удивительно.
Поменьше верьте Шишкину (касательно бтрфс). За большинством его высказываний в части бтрфс стоит банальная ревность и комплекс непризнанного гения.
> Поменьше верьте Шишкину (касательно бтрфс). За большинством его высказываний в части бтрфс
> стоит банальная ревность и комплекс непризнанного гения.Это как раз не проблема. Наоборот, проблема линукса в признанных псевдогениях, поделки которых проталкиваются корпорациями с такими усилиями, что порой удивляешься, как такое вообще могло попасть в стабильный дистрибутив.
+100500 а потом всем вместе предлагается решить проблемы от этих граблей.
> вообще могло попасть в стабильный дистрибутив.А чего такого криминального в btrfs? Обычная CoW, сделанная с оглядкой на другие, попытка сделать даже получше чем у других. У какого-нибудь ZFS и своих слабых мест - навалом, а если посмотреть на бенчи - btrfs вполне культурная в целом файловая система. А то что не во всех случаях идеально - так панацеи и не бывает. Всегда можно найти нагрузку на которой отдельно взятая ФС окажется хуже остальных. Только при таком раскладе файловыми системами вообще пользоваться не надо - они все г-но получатся. Ну я вот например могу загадить XFSный том до состояния когда 1 файл удаляется 30 секунд. Следует ли отсюда что XFS - г@вно? А может, отсюда следует что я подгадил ФС, вдарив по болючим местам?
>Ну я вот например могу загадить XFSный том до состояния когда 1 файл удаляется 30 секунд. Следует ли отсюда что XFS - г@вно?Да.
>>Ну я вот например могу загадить XFSный том до состояния когда 1 файл удаляется 30 секунд. Следует ли отсюда что XFS - г@вно?
> Да.Хорошо, а если я скажу что смогу загнать в задницу практически любую файловую систему, приложив должные усилия и выбрав наименее удобные для ФС условия - вы убьетесь о стену с разбега, осознав что мир жесток и неидеален? А то с таким критерием говенности ФС - каждая первая файловая система - гуано ;)
Конечно, для линукса гораздо лучше было бы если бы туда попало гениальнейшее творение компании разорившейся вскоре после того как ее глава сел за убийство и на поддержку которой впоследствии даже у того самого Шишкина не нашлось времени. Это сарказм если что, вот только Шишкин действительно так думает что и явилось причиной для наездов на бтрфс (а поводом какой-то извращенный тесткейс). Пинать разработчиков бтрфс может и стоит, но не потому что ее взяли в ядро а рейзер4 нет.
Использую для /home небольшой раздел на SSD. Юзаю сжатие в btrfs и reiser4.
На треть больше экономии места и прироста скорости на reiser4 по сравнению с btrfs. К несчастью вынужден был уйти с reiser4 тк есть баги и ежемесячно приходилось лечиться через fsck, ещё нет поддержки новых ядер. Шишкин писал, что у него нет времени исправить и доработать, а проспонсировать работу никому не интересно. Забросил он разработку сославшись, что юзайте btrfs. А это btfrs - убогое тормознутое впустую пожирающее пространство (проверял не исправили! matadata ratio) чудовище!
модуль zfs не подходит тк система x86_32 ради экономии места и памяти, а он тока на x86_64 без сигфолтов работает.
непонятно, чем вас zfs-fuse не устраивает. или именно оно имеется в виду под "модуль zfs"?
скоростью. а имеется ввиду именно модуль ядра zfsonlinux.org
Ничего не имею против Эдуарда Шишкина, но в данный момент и у рейзерфс есть нерешённые проблемы, о которых все знают довольно давно.
> Ничего не имею против Эдуарда Шишкина,... кроме того что в своем глазу он такое бревнище не заметил, на фоне которого проблемы btrfs вообще так, сущие мелочи.
Кому нужно тестировать btrfs, качают ее из git`а. Ибо в официальное ядро только сейчас некоторые весенние(!) патчи заслали (это я про будущее ядро 3.2).В рассылке btrfs самый популярный диалог:
- У меня бага! Не работает это и это...
- Знакомо... Какая у вас версия ядра?
- Самая новая... 3.0.xx
- Фи, батенька, мы уж про это старье не вспоминаем, ставьте распоследний 3.2.x-rcY или, в худшем случае, предпоследний, тогда и поговорим. ;)Так что обсуждать btrfs на основе впечатлений от пакетов, идущих в составе каких-либо дистрибутивов (даже горячо мной любимой Fedora) imho бессмысленно. Все ваши баги давно исправлены и вместо них сделаны новые :)
>Все ваши баги давно исправленыРазмечтался. Таким образом разработчики посылают всех, ибо лень попросту не хотят пытаться воспроизвести эти баги.
если только сидеть и исправлять баги то не останется времени на добавление новых фич.
если баги не исправлять, то новые фичи будут никому не нужны...
Будут, если не орать о багах на каждом углу
>> если баги не исправлять, то новые фичи будут никому не нужны...
> Будут, если не орать о багах на каждом углуПрямо Microsoft way (только фичи должны быть преимущественно сомнительные).
> Прямо Microsoft way
One Microsoft Way, Redmond, Washington, USA
> Размечтался. Таким образом разработчики посылают всех, ибо лень попросту не хотят пытаться
> воспроизвести эти баги.Время разработчиков - не резиновое! Поэтому снощаться с воспроизведением бага пойманного в заведомо тухлой версии часто не резон. Особенно если в "подозреваемый" кусок кода с тех пор вносились существенные изменения (а пиляют btrfs изрядно), а предоставленной информации - мало. В частности припоминаются какие-то изменения в свежих ядрах относительно fsync. В 3.1 и текущей версии как раз где-то.
> - Фи, батенька, мы уж про это старье не вспоминаем, ставьте распоследний
> 3.2.x-rcY или, в худшем случае, предпоследний, тогда и поговорим. ;)Ну так разработчики действительно могли починить over 9000 багов за этот период, в том числе перелопатить треть кода файловой системы, при этом возможно ваш баг уже давно зачинился. Время разработчиков не бесконечно, поэтому они не будут тратить его на разборку проблем в версиях отличных от самого свежака. И это правильно. Если вы заинтересованы в починке бага - пробуйте на свежаке. Это нормальный процесс багфиксинга и тестинга, он такой не только у линуксного ядра но и у множества иных проектов.
Проблема в том что они так уже слишком долго посылают за "свежим кодом". Активно слежу за сабжем года 2, как рабочая FS больше года. И вечный "мы знаем, fsync не очень быстр, но есть много идей, попробуйте приклеить красный треугольник к клетке с курицей". Нисколько не наезжаю на компетентность или трудолюбие Криса Мейсона и команды, но по факту лютый песец. Вопрос обещали снять к 3.0, потом к 3.1 "так как нужнв изменения в других подсистемах". И вот он, 3.1.
> И вечный "мы знаем, fsync не очень быстр, но есть много идей,Кроме идей, попадается еще и куча ченжлогов на эту тему. В частности что-то такое в оных по части fsync недавно было.
Кстати а где вы так злостно лупите fsync'ом что его скорость для вас - краеугольный камень прямо?
Выбешивает vim, иногда делает fsync (наверно периодически сохраняет на диске файл для восстановления при крэше), до 20+ (!!!) секунд доходит зависоны. Вставил 2 символа, только жмякнул PgUp и привет. Редко, не спорю. Раз в час- пол часа. Но метко, как раз в момент, когда нужно сбросить свежепридуманую идею пока не забыл детали.Любое обновление yum update превращается в ад. Там тонны fsync, так как нужно быть уверенным в том что данные нового пакета таки записаны. Собственно с этой претензии обычно и начинаются разборки в btrfs-devel. Годами. Вот и ныне там . C kernel 3.1.
Загрузка ОС дольше раза в 4. На глазок - btrfs превратила комп в венду.
не знаю, что у вас не так, но когда у меня появляются тормоза на Fedora (примерно раз в 2-3 месяца, после кучи апдейтов), мне помогает btrfs fi balance / ну и как вариант можно попробовать дефрагментировать раздел
> ну и как вариант можно попробовать дефрагментировать раздел
>>На глазок - btrfs превратила комп в венду.
> восстановления при крэше), до 20+ (!!!) секунд доходит зависоны.Ну вот это - совсем непорядок. Факт!
> Любое обновление yum update превращается в ад.
Не хочу ничего сказать, но когда я пользовался шапкой, меня скорость работы yum выбешивала и на EXT3. А на виртуалках с 256 мегами памяти ему вообще оперативы не хватало для установки особо жирных пакетов. Yum мне запомнился как мерзкий и тормозной пакетный менеджер, уж извините.
> Там тонны fsync, так как нужно быть уверенным в том что данные нового пакета таки записаны.
На самом деле федористы помнится пилили специально для бтр-а намного более умный подход: до апдейта лепится снапшот (достаточно 1 раз синкануть именно его на диск) а далее ставятся апдейты. Не понравилось? И хрен с ним! Откатимся на снапшот и готово, можно попробовать еще раз. Зачем при таком подходе вообще fsync-ать все и вся - загадка природы. Может недоделали еще эту логику?
> Собственно с этой претензии обычно и начинаются разборки в btrfs-devel. Годами.
> Вот и ныне там . C kernel 3.1.По моим наблюдениям, за пару лет btrfs прилично подтянули. Хотя честно говоря я никогда ее не бенчил на предмет кучи fsync, но как минимум sqlite там стал работать заметно резвее (он с его журналами тоже упирался в это, да и продолжает). Но вообще, а вы не погорячились использовать ее как загрузочную ФС в боевой системе то? Федористы вон отложили переход на оную как дефолтную на как минимум 1 релиз, что как бы намекает что зелен виноград. Всему свое время и место.
> Загрузка ОС дольше раза в 4. На глазок - btrfs превратила комп в венду.
В 4 раза - по сравнению с чем? С ext4? Ну так EXT4 не умеет и 1/10 того что умеет btrfs. Хотя все-равно - не понятно чему там в 4 раза тормозить. У вас времена доступа к файлам чтоли включены? Или чего оно там в 4 раза делает? А bootchart посмотреть и вообще запрофайлить что и где затыкается? Систему грузить честно говоря не пробовал (я не камикадзе, извините) а как data диск оно вроде довольно съедобно уже работает. Хотя от набора файлов и операций зависит, разумеется.
> нехорошее. Под F16-RC2 тормозища неописуемые при fsync.Если это с распоследним кернелом - ну так отпишите в список рассылки. А то знаете, там давно уже в этой заварушке не только оракл но и еще орава разработчиков со всех сторон.
Вроде Йозеф исправил проблемы с медленным synq. Если не лень, можете проверить из его ветви git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git
Спасибо, я в курсе. Просто обещал он еще в 3.0. Потом совcем-совсем починим в 3.1. Теперь снова... Я то переживу, просто других тестировщиков предупреждаю.
Ещё стоит отметить, что существует утилита для восстановления данных, написанная Йозефом. Работает она в ro, так что если у кого-то есть сломанные разделы с btrfs - стоит попробовать.
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git recovery-beta