LINUX.ORG.RU

Глюки у диска с btrfs

 , ,


0

2

Сейчас пишу с live образа, на диске стоит раздел с btrfs, внезапно начали падать Кеды, сначала думал прилетел кривой апдейт, а потом увидел, что в терминале начали появляться I/O Errors, при попытке что-то запустить и терминал не мог открыть htop, и некоторые другие утилиты, говоря, что исполняемый файл отсутствует.

Загрузился с live флешки, примонтировал /dev/sda1 в /mnt, файлы нормально читаются, сделал бэкапы, перепроверил, важные данные целы и на месте.

Отмонтировал раздел и сделал проверку:

sudo btrfs check /dev/sda1
Opening filesystem to check...
Checking filesystem on /dev/sda1
UUID: 401b4f1e-325a-4c6a-97ce-b580690e3a2c
[1/7] checking root items
[2/7] checking extents
parent transid verify failed on 456654848 wanted 82864 found 82810
parent transid verify failed on 456785920 wanted 82864 found 82810
parent transid verify failed on 456785920 wanted 82864 found 82810
parent transid verify failed on 456785920 wanted 82864 found 82810
Ignoring transid failure
parent transid verify failed on 461619200 wanted 82864 found 82809
parent transid verify failed on 454688768 wanted 82864 found 82808
parent transid verify failed on 456638464 wanted 82864 found 82808
parent transid verify failed on 456687616 wanted 82864 found 82810
parent transid verify failed on 456687616 wanted 82864 found 82810
parent transid verify failed on 456687616 wanted 82864 found 82810
Ignoring transid failure
parent transid verify failed on 456704000 wanted 82864 found 82808
parent transid verify failed on 456704000 wanted 82864 found 82808
parent transid verify failed on 456704000 wanted 82864 found 82808
Ignoring transid failure
parent transid verify failed on 456720384 wanted 82864 found 82810
parent transid verify failed on 456720384 wanted 82864 found 82810
parent transid verify failed on 456720384 wanted 82864 found 82810
Ignoring transid failure
parent transid verify failed on 456753152 wanted 82864 found 82808
parent transid verify failed on 456753152 wanted 82864 found 82808
parent transid verify failed on 456753152 wanted 82864 found 82808
Ignoring transid failure
parent transid verify failed on 456769536 wanted 82864 found 82808
parent transid verify failed on 456769536 wanted 82864 found 82808
parent transid verify failed on 456769536 wanted 82864 found 82808
Ignoring transid failure
parent transid verify failed on 456818688 wanted 82864 found 82810
parent transid verify failed on 456818688 wanted 82864 found 82810
parent transid verify failed on 456818688 wanted 82864 found 82810
Ignoring transid failure
parent transid verify failed on 456835072 wanted 82864 found 82810
parent transid verify failed on 456835072 wanted 82864 found 82810
parent transid verify failed on 456835072 wanted 82864 found 82810
Ignoring transid failure
parent transid verify failed on 456851456 wanted 82864 found 82810
parent transid verify failed on 456851456 wanted 82864 found 82810
parent transid verify failed on 456851456 wanted 82864 found 82810
Ignoring transid failure
parent transid verify failed on 456867840 wanted 82864 found 82810
parent transid verify failed on 456867840 wanted 82864 found 82810
parent transid verify failed on 456867840 wanted 82864 found 82810
Ignoring transid failure
Segmentation fault

В файловых системах я не «бум-бум», что дальше делать не знаю. Ещё стоит уточнить, диск не обычный, это SSHD гибрид, ошибок раньше он не показывал, проработал несколько месяцев.

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

★★★
Ответ на: комментарий от firkax

ссд превращает каждый из 5 блоков например в среднем в 2 блока

На это можно забить, оно не идёт в SMART вроде. То есть пофиг, что оно там у себя внутри делает. Так можно начать беспокоиться о перезаписи SLC в TLC/QLC, которая есть в любом современном SSD.

anonymous
()
Ответ на: комментарий от vbcnthfkmnth123

Я уже много раз видел подобного рода комментарии про сводобное место на BTRFS и возможность удаления файлов, но ведь это нифига так просто не воспроизводится. Я забивал место полностью, все равно файлы можно удалить без проблем.

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

Ну и где тут ошибка btrfs ? Тут наоборот сказать надо ей спасибо что данные уцелели.
Вот другое бесит- ошибка на 1 сектор,головка промахнулась,бывает или Бад блок,а система в раскорячку становится.Crc не хватает чтобы парировать ошибку,а алгоритм починки с потерей данных- (пусть и заносом в lost+ ) это знание нынешними программистами утраченное . Т.е просто предлагают ставить рэйд1 и не заморачиваться.Бэд
блоки с исправной копии система восстановит а с fsck авторы будут думать когда рак свистнет.

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

Не насилует.Во первых по умолчанию для SSD только одна копия метаданных.Во вторых внезапно f2fs использует тоже COW. Другое дело что некоторые опции предлагают включать по не знанию, допустим Trim .

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

Чекни диск сколько пишет за 10 минут

btrace -w 600 -a write /dev/sdx
А так можно будет посмотреть что кто конкретно пишет
iotop -obPat
Это все от рута запускать. А так я ориентировался на эти данные - https://arxiv.org/pdf/1707.08514.pdf

Там примерно brtfs пишет в несколько раз больше, чем ext4.

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

алгоритм починки с потерей данных- (пусть и заносом в lost+ ) это знание нынешними программистами утраченное

Сознательно утраченное. Данные должны быть корректными, некорректные данные не нужны.

anonymous
()
Ответ на: комментарий от vbcnthfkmnth123

У меня 80% пишет журнал ситстемд.Выходит где то 1,5 мгб за 10 минут.Все.А на флэшку не хрена не пишет.Но я некоторые опции на ссд отключил- балансировка и дефрагментация,поставил изменять время доступа только при модификации файла.Но у меня 2 диска,модель ноутбука удачная в этом отношении .Я кинул на ссд редко изменяющие разделы чтобы сэкономить ресурс,но при этом ускорить загрузку.(с boot заморачиваться не стал,хотя загрузка с Флэш возможна)

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

некорректные данные не нужны.

Я уже видел одну такую фс .Ещё потдерживается,но уже на грани вымирания,а все потому что тоже заложили дублирование и crc,но средств починки нету.Подсказать как эта фс называется или нет? (Кроссплатформенная,потдерживается практически всеми современными операционками,но не фат)

Правильно ,Ватсон .UDF .И когда пошел офтопик 10- у него был баг- какой то атрибут не правильно записывал из за этого драйвер под lin считал эту фс не корректно размонтированной.Данные целые а работать с ней нельзя.... Только форматирование.Тут и возникает вопрос целесообразности что лучше - фс которая от любого глюка становится раком или фс которая может до фига ошибок скорректировать,но с потерей данных.Что то на ext4 в этом отношении не жалуются,хотя я сам когда-то словил глюк с потерей 500 мгб данных,можно поискать по архивам,но с проверкой пакетов все востоновил.home раздел не пострадал тогда.

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

и действительно сейчас посмотрел диск переодически моргает своим лампочкой.

Он даже при отсутствии записей будет моргать, там какой-то heartbeat в ядре на эту лампочку сделан. Если ничего не пишет\читает, то раз в секунду(вроде) всё равно моргнет. Я тоже раньше думал «чего это он там пишет\читает?», а недавно ссылка на коммит в ядро проскакивала(тут на лоре) как раз об этом.

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

все равно файлы можно удалить без проблем.

Этот глюк поправили.Теперь есть возможность выделение дополнительно место для методанных,с какой то версии ядра по умолчанию.Вот как можно было на одни и те же грабли с ext наступать,в смысле статическое выделение места,только на ext2-4 это иноды и экстэнты,а у бтрфс страйпы.По умолчанию очень мелкие файлы пишутся в методанные, и при большом их количестве и постоянной модификации - методанные COW страйпа растут на дрожжах.А потом бац и место кончилось,а в чужой страйп по дизайну писать нельзя (вообще то можно,есть опция комбинированных страйпов,но это рассчитано на небольшие объемы) .Иногда балансировка помогала.,но народ офигивал как так при свободном объеме не хрена нечего не сделаешь....

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

Сознательно утраченное. Данные должны быть корректными, некорректные данные не нужны.

Согласен на картинку с «битым пикселем», чем на потерю всей фотки вообще. Да даже на документацию с потерянной страницей согласен, чем потерять целиком данные.

Сколько раз встречалось, что на скачанном фильме побились несколько килобайт, они перекачиваются и всё нормально. А так бы мне что, все 70Гб заново качать?

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

Резервные копии файлопомойки на несколько ТБ? Спасибо не нужно. Резервные копии нужны только действительно важных данных, но и устойчивость к мелким повреждениям у ФС должна быть. Я так от XFS отказался, потому что она у меня через раз валилась насмерть от потери питания. С Ext4 такого за 10 лет замечено не было, максимум fsck надо было сделать.

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

Не, ну если у тебя регулярно портятся данные и это в принципе устраивает, то никто не заставляет использовать файловые системы с контрольными суммами для данных. Вообще это не очень нормально, что они портятся, в первую очередь.

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

И это тоже не очень нормально. Либо монтировал с nobarrier (когда это было ещё возможно), либо с железом проблемы.

anonymous
()
Ответ на: комментарий от anonymous

Вообще это не очень нормально, что они портятся, в первую очередь.

Почему портятся - не знаю, но бывает, что фильм лежит скачанный пару лет, и при проверке его целостности, он перекачивает немного. Я думаю это те куски, что раз в несколько месяцев находит fsck.

И это тоже не очень нормально. Либо монтировал с nobarrier (когда это было ещё возможно), либо с железом проблемы.

Это было в 2010-2012, наверное тогда были дефолты такие. Но из-за того что я периодически ловил 12309, то приходилось ресетом перезагружаться. XFS от этого дох насмерть.

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

См выше я ответил на вопрос.+ +Теперь выделяется место для самой фс,чтобы к примеру сделать удаление.Потому что без записи в методанные с данными нечего сделать нельзя,это особенность COW.

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

Добавлю.У ехт сейчас тоже при нынешних объемах дисков вылазит ошибка нет места.Под иноды выделяется при форматирование сколько то % от объема, обычно хватает.Может не хватать при большом обьеме мелких файлов,нехватку
извратившись можно поправить с помощью LVM.Также есть глюк только с большим объемом файлов в каталоге : не сразу освобождаются иноды при удалении этих файлов-при некоторых условиях тоже можно словить нехватку места при свободном объеме.Чиниться опцией D при прогоне fsck ,это к сожалению неустранимый недостаток ext.

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

На xfs словил такое - каталог был, выключил комп корректно, включил на следующий день - нет каталога. Нету и всё, fsck ничего не нашёл, в lost+found пусто. На этом нескучные ФС для себя закрыл. Начиная с ext3 ничего не билось даже при отключении из розетки.

yu-boot ★★★★★
()