| 1.1, BliecanBag (ok), 14:56, 01/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Отлично! Просто отлично! C ужасом жду выхода и результатов проверки своих разделов ~1.5 годичной давности
| | |
| |
| 2.2, Frank (ok), 15:45, 01/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Проверить (и убедиться в наличии каких-то мелких косячков) можно уже с пол года как, только исправлять пока оно не берётся :) Так что ждать надо с радостью, а не ужасом! ;)
| | |
| |
| 3.17, Аноним (-), 18:39, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Хм, что значит - не берутся? А что же тогда за пачки исправлений в ченжлогах ядра? Или починенный баг за баг не считается? :)
| | |
| |
| 4.19, K.O. (?), 19:39, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Речь об исправлении ошибок в вашей файловой системе, а не в коде ядра.
Вот так-то!
| | |
| |
| 5.21, Аноним (-), 20:12, 01/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дык разговор еще только идет о выпуске бета-версии fsck. И чего вы ожидали? Кстати у ZFSных камикадзей fsck вообще нету а как они исправляют ошибки - можно на лисяре почитать, там хардкор с ручным редактированием структур файловой системы вообще ;)
| | |
| |
| 6.34, iZEN (ok), 22:57, 01/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Дык разговор еще только идет о выпуске бета-версии 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&sektion=0&manpath=Fr
В котором описана волшебная команда zpool scrub pool...
| | |
| |
| 7.38, Аноним (-), 02:30, 02/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> import -F poolname". Производится поиск последних завершённых групп транзакций и восстановления
> состояния непротиворечивости по ним.
Ну так это заткнули для одной конкретной ситуации, видимо похожей на то что недавно в списке рассылки btrfs было. А полноценного fsck - нету.
> Разницы в скорости импортирования с ключом "-F" и без на неповреждённом пуле
> не заметил.
В случае починки основательно разваленной ФС волновать будет не скорость. Программно - всяко быстрее чем ручками файлы доставать, вручную парся структуры с калькулятором и хексредактором, потому что сама ФС видите ли облажалась и выпала в немоунтабельное состояние или состояние при котором драйвер с грохотом валится.
> Чтобы больше не попадать впросак с заявлениями о невозможности восстановления ZFS или
> необходимости в ручном редактировании структур файловой системы,
Гораздо интереснее было бы посмотреть на твою мину при восстановлении всерьез рассыпавшегося пула, когда драйвер не сможет это подхватить, а полноценных утилей восстановления как бы и нету толком.
> И, да, у ZFSных камикадзей есть man zpool:
> В котором описана волшебная команда zpool scrub pool...
А толку? Это не есть полный аналог fsck.
| | |
| |
| 8.44, iZEN (ok), 14:31, 02/11/2011 [^] [^^] [^^^] [ответить] | +/– | Свежий случай на системном пуле, заполненном на 99 от полезной ёмкости не найд... текст свёрнут, показать | | |
|
|
|
|
|
| 3.35, Аноним (-), 23:23, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Омг... а я как-то и не заморачивался с восстановлением, думал оно есть... уже не стал вникать в суть, но опытным путём обнаружил, что помогала перестановка загрузчика(на /boot был не btrfs).
Я, конечно, попытаюсь погуглить на досуге, но подскажите, пожалуйста: как это работало!?
Неужели, таблицы ФС связаны с загрузчиком?
| | |
|
|
| 1.4, anonymous (??), 16:59, 01/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
К сожалению подтверждаются мои худшие подозрения: Оракл мутит с btrfs что то нехорошее. Под F16-RC2 тормозища неописуемые при fsync. Короче народ, даже не думайте, ставьте только ext4, xfs и прочее провереное. Не вышел каменный цветок. А как дысал, как дысал...
| | |
| |
| 2.6, BratSinot (?), 17:34, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Вспоминая интервью Шишкина где он рассказал как этот Btrfs устроен не удивительно.
| | |
| |
| 3.7, антоним (?), 17:41, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Поменьше верьте Шишкину (касательно бтрфс). За большинством его высказываний в части бтрфс стоит банальная ревность и комплекс непризнанного гения.
| | |
| |
| 4.10, anonymous (??), 18:03, 01/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Поменьше верьте Шишкину (касательно бтрфс). За большинством его высказываний в части бтрфс
> стоит банальная ревность и комплекс непризнанного гения.
Это как раз не проблема. Наоборот, проблема линукса в признанных псевдогениях, поделки которых проталкиваются корпорациями с такими усилиями, что порой удивляешься, как такое вообще могло попасть в стабильный дистрибутив.
| | |
| |
| 5.11, jaja (?), 18:17, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
+100500 а потом всем вместе предлагается решить проблемы от этих граблей.
| | |
| 5.22, Аноним (-), 20:17, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> вообще могло попасть в стабильный дистрибутив.
А чего такого криминального в btrfs? Обычная CoW, сделанная с оглядкой на другие, попытка сделать даже получше чем у других. У какого-нибудь ZFS и своих слабых мест - навалом, а если посмотреть на бенчи - btrfs вполне культурная в целом файловая система. А то что не во всех случаях идеально - так панацеи и не бывает. Всегда можно найти нагрузку на которой отдельно взятая ФС окажется хуже остальных. Только при таком раскладе файловыми системами вообще пользоваться не надо - они все г-но получатся. Ну я вот например могу загадить XFSный том до состояния когда 1 файл удаляется 30 секунд. Следует ли отсюда что XFS - г@вно? А может, отсюда следует что я подгадил ФС, вдарив по болючим местам?
| | |
| |
| 6.36, Школьник (ok), 23:23, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
 >Ну я вот например могу загадить XFSный том до состояния когда 1 файл удаляется 30 секунд. Следует ли отсюда что XFS - г@вно?
Да.
| | |
| |
| 7.39, Аноним (-), 02:32, 02/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Ну я вот например могу загадить XFSный том до состояния когда 1 файл удаляется 30 секунд. Следует ли отсюда что XFS - г@вно?
> Да.
Хорошо, а если я скажу что смогу загнать в задницу практически любую файловую систему, приложив должные усилия и выбрав наименее удобные для ФС условия - вы убьетесь о стену с разбега, осознав что мир жесток и неидеален? А то с таким критерием говенности ФС - каждая первая файловая система - гуано ;)
| | |
|
|
| 5.32, антоним (?), 21:48, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Конечно, для линукса гораздо лучше было бы если бы туда попало гениальнейшее творение компании разорившейся вскоре после того как ее глава сел за убийство и на поддержку которой впоследствии даже у того самого Шишкина не нашлось времени. Это сарказм если что, вот только Шишкин действительно так думает что и явилось причиной для наездов на бтрфс (а поводом какой-то извращенный тесткейс). Пинать разработчиков бтрфс может и стоит, но не потому что ее взяли в ядро а рейзер4 нет.
| | |
|
| 4.33, runoverheads (ok), 22:38, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Использую для /home небольшой раздел на SSD. Юзаю сжатие в btrfs и reiser4.
На треть больше экономии места и прироста скорости на reiser4 по сравнению с btrfs. К несчастью вынужден был уйти с reiser4 тк есть баги и ежемесячно приходилось лечиться через fsck, ещё нет поддержки новых ядер. Шишкин писал, что у него нет времени исправить и доработать, а проспонсировать работу никому не интересно. Забросил он разработку сославшись, что юзайте btrfs. А это btfrs - убогое тормознутое впустую пожирающее пространство (проверял не исправили! matadata ratio) чудовище!
модуль zfs не подходит тк система x86_32 ради экономии места и памяти, а он тока на x86_64 без сигфолтов работает.
| | |
| |
| 5.40, антоним (?), 12:16, 02/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
непонятно, чем вас zfs-fuse не устраивает. или именно оно имеется в виду под "модуль zfs"?
| | |
|
|
| 3.27, fyjybvec (?), 21:16, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Ничего не имею против Эдуарда Шишкина, но в данный момент и у рейзерфс есть нерешённые проблемы, о которых все знают довольно давно.
| | |
| |
| 4.29, Аноним (-), 21:33, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Ничего не имею против Эдуарда Шишкина,
... кроме того что в своем глазу он такое бревнище не заметил, на фоне которого проблемы btrfs вообще так, сущие мелочи.
| | |
|
|
| 2.8, dalco (ok), 17:50, 01/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Кому нужно тестировать btrfs, качают ее из git'а. Ибо в официальное ядро только сейчас некоторые весенние(!) патчи заслали (это я про будущее ядро 3.2).
В рассылке btrfs самый популярный диалог:
- У меня бага! Не работает это и это...
- Знакомо... Какая у вас версия ядра?
- Самая новая... 3.0.xx
- Фи, батенька, мы уж про это старье не вспоминаем, ставьте распоследний 3.2.x-rcY или, в худшем случае, предпоследний, тогда и поговорим. ;)
Так что обсуждать btrfs на основе впечатлений от пакетов, идущих в составе каких-либо дистрибутивов (даже горячо мной любимой Fedora) imho бессмысленно. Все ваши баги давно исправлены и вместо них сделаны новые :)
| | |
| |
| 3.9, anonymous (??), 17:58, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Все ваши баги давно исправлены
Размечтался. Таким образом разработчики посылают всех, ибо лень попросту не хотят пытаться воспроизвести эти баги.
| | |
| |
| 4.12, Lexa (??), 18:18, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
если только сидеть и исправлять баги то не останется времени на добавление новых фич.
| | |
| |
| 5.18, trdm (ok), 18:46, 01/11/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
 если баги не исправлять, то новые фичи будут никому не нужны...
| | |
| |
| |
| 7.48, Ytch (?), 03:13, 03/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> если баги не исправлять, то новые фичи будут никому не нужны...
> Будут, если не орать о багах на каждом углу
Прямо Microsoft way (только фичи должны быть преимущественно сомнительные).
| | |
|
|
|
| 4.16, Аноним (-), 18:37, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Размечтался. Таким образом разработчики посылают всех, ибо лень попросту не хотят пытаться
> воспроизвести эти баги.
Время разработчиков - не резиновое! Поэтому снощаться с воспроизведением бага пойманного в заведомо тухлой версии часто не резон. Особенно если в "подозреваемый" кусок кода с тех пор вносились существенные изменения (а пиляют btrfs изрядно), а предоставленной информации - мало. В частности припоминаются какие-то изменения в свежих ядрах относительно fsync. В 3.1 и текущей версии как раз где-то.
| | |
|
| 3.15, Аноним (-), 18:34, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> - Фи, батенька, мы уж про это старье не вспоминаем, ставьте распоследний
> 3.2.x-rcY или, в худшем случае, предпоследний, тогда и поговорим. ;)
Ну так разработчики действительно могли починить over 9000 багов за этот период, в том числе перелопатить треть кода файловой системы, при этом возможно ваш баг уже давно зачинился. Время разработчиков не бесконечно, поэтому они не будут тратить его на разборку проблем в версиях отличных от самого свежака. И это правильно. Если вы заинтересованы в починке бага - пробуйте на свежаке. Это нормальный процесс багфиксинга и тестинга, он такой не только у линуксного ядра но и у множества иных проектов.
| | |
| 3.20, anonymous (??), 20:04, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Проблема в том что они так уже слишком долго посылают за "свежим кодом". Активно слежу за сабжем года 2, как рабочая FS больше года. И вечный "мы знаем, fsync не очень быстр, но есть много идей, попробуйте приклеить красный треугольник к клетке с курицей". Нисколько не наезжаю на компетентность или трудолюбие Криса Мейсона и команды, но по факту лютый песец. Вопрос обещали снять к 3.0, потом к 3.1 "так как нужнв изменения в других подсистемах". И вот он, 3.1.
| | |
| |
| 4.23, Аноним (-), 20:20, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> И вечный "мы знаем, fsync не очень быстр, но есть много идей,
Кроме идей, попадается еще и куча ченжлогов на эту тему. В частности что-то такое в оных по части fsync недавно было.
Кстати а где вы так злостно лупите fsync'ом что его скорость для вас - краеугольный камень прямо?
| | |
| |
| 5.24, anonymous (??), 20:40, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Выбешивает vim, иногда делает fsync (наверно периодически сохраняет на диске файл для восстановления при крэше), до 20+ (!!!) секунд доходит зависоны. Вставил 2 символа, только жмякнул PgUp и привет. Редко, не спорю. Раз в час- пол часа. Но метко, как раз в момент, когда нужно сбросить свежепридуманую идею пока не забыл детали.
Любое обновление yum update превращается в ад. Там тонны fsync, так как нужно быть уверенным в том что данные нового пакета таки записаны. Собственно с этой претензии обычно и начинаются разборки в btrfs-devel. Годами. Вот и ныне там . C kernel 3.1.
Загрузка ОС дольше раза в 4. На глазок - btrfs превратила комп в венду.
| | |
| |
| 6.25, BliecanBag (ok), 20:53, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
не знаю, что у вас не так, но когда у меня появляются тормоза на Fedora (примерно раз в 2-3 месяца, после кучи апдейтов), мне помогает btrfs fi balance / ну и как вариант можно попробовать дефрагментировать раздел
| | |
| 6.30, Аноним (-), 21:46, 01/11/2011 [^] [^^] [^^^] [ответить] | +/– | Ну вот это - совсем непорядок Факт Не хочу ничего сказать, но когда я пользова... большой текст свёрнут, показать | | |
|
|
|
|
| 2.14, Аноним (-), 18:29, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> нехорошее. Под F16-RC2 тормозища неописуемые при fsync.
Если это с распоследним кернелом - ну так отпишите в список рассылки. А то знаете, там давно уже в этой заварушке не только оракл но и еще орава разработчиков со всех сторон.
| | |
| 2.26, fyjybvec (?), 21:10, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Вроде Йозеф исправил проблемы с медленным synq. Если не лень, можете проверить из его ветви git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git
| | |
| |
| 3.31, anonymous (??), 21:46, 01/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо, я в курсе. Просто обещал он еще в 3.0. Потом совcем-совсем починим в 3.1. Теперь снова... Я то переживу, просто других тестировщиков предупреждаю.
| | |
|
|
| 1.28, fyjybvec (?), 21:20, 01/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ещё стоит отметить, что существует утилита для восстановления данных, написанная Йозефом. Работает она в ro, так что если у кого-то есть сломанные разделы с btrfs - стоит попробовать.
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git recovery-beta
| | |
|
