LINUX.ORG.RU
решено ФорумAdmin

Не могу удалить каталог -Btrfs глючит

 , жесткий диск,


0

7

Здравствуйте.
Словил глюк -не могу удалить каталог в орт на отдельном разделе.
btrfs scrub ошибок не нашел !!!
btrfs check --repair /dev/sda3 ошибок не выявил,смарт в норме . Виктория бад блоков не выявила.Поясняю удаляеться нормально,ошибок нет,но после перезагрузки или монтирования происходит откат с указанной ошибкой.
Из бэкапа как говориться я всегда могу раздел востановить ,но блин считай сутки терять не охота .Есть рецепт починить проблему ?

Лог ошибок:

823.197293] BTRFS critical (device sda3): corrupt leaf: block=2669677215744 slot=35 extent bytenr=2220399398912 len=36864 invalid data ref objectid value 18446744073709551604
[  823.197315] BTRFS error (device sda3): read time tree block corruption detected on logical 2669677215744 mirror 1
[  823.205394] BTRFS critical (device sda3): corrupt leaf: block=2669677215744 slot=35 extent bytenr=2220399398912 len=36864 invalid data ref objectid value 18446744073709551604
[  823.205400] BTRFS error (device sda3): read time tree block corruption detected on logical 2669677215744 mirror 2
[  823.205439] BTRFS error (device sda3: state A): Transaction aborted (error -5)
[  823.205445] BTRFS: error (device sda3: state A) in __btrfs_free_extent:3273: errno=-5 IO failure
[  823.205449] BTRFS info (device sda3: state EA): forced readonly
[  823.205452] BTRFS error (device sda3: state EA): failed to run delayed ref for logical 2220449775616 num_bytes 77824 type 178 action 2 ref_mod 1: -5
[  823.205457] BTRFS: error (device sda3: state EA) in btrfs_run_delayed_refs:2277: errno=-5 IO failure
[  823.206096] BTRFS info (device sda3: state EA): last unmount of filesystem 6575f960-d7e4-44da-af07-3a4a80397ded
[  828.473781] BTRFS: device label opt devid 1 transid 63295 /dev/sda3 scanned by mount (4826)
[


Уточняю: мелкими блоками я все таки папку почистил, остались только не удаляемые файлы.Теперь scrub отваливается от ошибки вода-вывода . Дополню -файлы с помощью rsunc -c с раздела скопировал,ошибок не было.На всякий случай с другим бэкапом сравню.Так что если решение не найдется раздел снесу отформатироваю.
Решено.
Вспомнил я про Parted Magic от 22 года, который платный но добрые люди скинули в сеть.Он тоже ругался на метаданные в журнале но папку то удалил .




Перемещено hobbit из general

★★

Последнее исправление: maximnik0 (всего исправлений: 4)
Ответ на: комментарий от mx__

Сколько с пустыми файлами бились на XFS ? Особенно этот баг досаждал торренщикам - все скачали нормально,выключили- включили а файлов тю-тю, пустые . Да, сейчас очень многое поправили- но сжатия нет, контрольной суммы для данных нет. С снимками тоже похуже ,нет такой гибкости.А надёжность особенно черепичных жёстких «веселит» . Есть факты что ноутбучные черепичные спустя 2 года запись черепицей с трудом читают,т.е нужно давать сервисной программе диска перезаписывать данные:-(

maximnik0 ★★
() автор топика
Ответ на: комментарий от ptah_alexs

Толкнули ноутбук - вот и промах получили. Да и нашла то промах там где я до этого не проверял а в журнале ошибок нет, видать удаленный файл или свободное место.Хотя конечно надёжность упала у дисков- но видел реально щелкающий диск, стартует где то через минуту с 2-3 попытки,смарт Алерт горит ,но уже 3 месяца живёт и работает каждый день.Если не заводской брак- головка не повреждена и поверхность - редкие Бад блоки допустимы , они могут годами не расширяется: в основном исчерпывается ресурс подшипников, начинаются ошибки чтения -записи и в течение недели жёсткий выходит из строя.Вот этот момент важно не упустить.

maximnik0 ★★
() автор топика
Последнее исправление: maximnik0 (всего исправлений: 1)
9 октября 2025 г.

В общем оказывается народ прав что это аппаратная проблема. Опять в логах появилась ошибка в метаданных только в другом блоке. Думаю что то тут не чисто - а почему Smart то молчит? Перекатал все данные на новый диск ,благо на данные не ругались ядро .Стал гонять smart с полной проверкой - сразу появилось 12 переназначенных блоков вместо 1 слабого. Вывод - нехорошие азиаты что то нахимичили в NVMe М.2 переходнике - какие то команды для Смарта тупо не проходят на диск :-(

maximnik0 ★★
() автор топика
Последнее исправление: maximnik0 (всего исправлений: 1)
Ответ на: комментарий от MoldAndLimeHoney

В общем все таки оказалось что диск имеет аппаратные проблемы.Китайцы на M.2 переходнике как то зажали smart протокол и у меня smart тесты проходили без проблем.Но опять вылезла ошибка в метаданных - а это уже диагноз что явно что то не то.Поставил я новый диск а старый на smart полную диагностику через юсб переходник (хороший) , который даже с Блю рей приводами работает- и все, сразу смарт 12 сбойных блоков выявил . Вот так то,Виктория нечего не находила а btrfs уже начал ругаться.В этот раз btrfs все таки ПРИЯТНО удивила.

maximnik0 ★★
() автор топика
Ответ на: комментарий от maximnik0

Сколько с пустыми файлами бились на XFS ?

Кто бился?

Особенно этот баг досаждал торренщикам - все скачали нормально,выключили- включили а файлов тю-тю, пустые.

C 2010 года не имел такого.

контрольной суммы для данных нет.

Ты про V5 слышал вообще?

Ololo_Trololo ★★
()
Последнее исправление: Ololo_Trololo (всего исправлений: 1)
Ответ на: комментарий от Ololo_Trololo

Ты про V5 слышал вообще?

Слышал. Но если вы не знали контрольная сумма только для метаданных.
Есть эксперементальные падчи с поддержкой контрольной суммы для данных на основе FS Verity и есть наработки для XFS , но там нужно ломать совместимость.

Кто бился?

Полно было криков - питание вырубило куча файлов пустые 0 бит .Посмотрите старые форумы где то 05 годов , и да только в версии 5 какой то ревизии этот баг устранили,просто лень рыться на oppenet.ru .

C 2010 года не имел такого.


этот баг очень оперативно устранили буквально в 1-2 ревизиях ядра и торрент клиента.

maximnik0 ★★
() автор топика
Ответ на: комментарий от maximnik0

Посмотрите старые форумы где то 05 годов , и да только в версии 5 какой то ревизии этот баг устранили,просто лень рыться на oppenet.ru .

Мало того, что тогда линуксом не пользовался, так даже торрентам не пользовался.

Но если вы не знали контрольная сумма только для метаданных.

Даже с V4 не имел проблем всё это время. По моим личным наблюдениям XFS наиболее усточива к внезапным отключения питания, а его у нас частенько отрубали. EXT4 теряла данные, F2FS просто тупо ломалась почти полностью.

Ololo_Trololo ★★
()
Последнее исправление: Ololo_Trololo (всего исправлений: 2)
Ответ на: комментарий от Ololo_Trololo

По моим личным наблюдениям

Ну это как повезет -теория вероятностей. Но технически в версии 4 устойчивость XFS хуже -там журналирование происходит только по метаданным, а не по блокам файлов .В 5 версии COW ,эта штука сама по себе гораздо устойчевее к сбоям,но с методанными обычно беда :-(.А у ext4 можно было включить режим полное журналирование (journal) — в журнал записываются и метаданные, и изменения в самом файле. Но глюки можно словить на любой фс - я на ровном месте при плановой проверке когда то на ext4 еще без crc для методанных словил ступор что fsck в lost+found отправила 500 мгб системных файлов :-(

maximnik0 ★★
() автор топика
Последнее исправление: maximnik0 (всего исправлений: 3)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.