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

★★★

Я перешел на btrfs несколько месяцев назад. За это время у меня два раза были проблемы ФС с потерей конфигов на системном диске и отваливанием доступа к разделам другого диска с файлопомойкой.
Наверное, я – рукожоп, и не проникся парадигмой, но рекомендую всячески избегать этого поделия. ИМХО. ext4 рулит и педалит уже много лет, и таких проблем на ней я не видел.

Сорри, подсказать именно по твоей проблеме не могу.

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

Нет, размер диска ни при чём. Увеличивается количество сделанных записей. Оно влияет на ресурс ссд и на производительность. Насчёт 10 раз у бтрфс - не в курсе. Усиление есть практически у всех фс, но у каких то оно особенно большое.

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

Я перешел на btrfs несколько месяцев назад. За это время у меня два раза были проблемы ФС с потерей конфигов на системном диске и отваливанием доступа к разделам другого диска с файлопомойкой.

Конфигурацию железа в студию. Особенно модели накопителей.

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

Ок, проверю, сегодня весь день сижу с live образа загруженного в ОЗУ, проблем пока не замечал.

Сейчас запускаю S.M.A.R.T. тесты, как завершатся отпишу результат.

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

Вот я не понимаю — вроде уважаемого человека из себя строишь, о каких-то датацентрах там пытаешься рассуждать, «выкаешь» демонстративно — а разговариваешь как гопота подзаборная.

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

Поддержка trim по дефолту подразумевается

Когда ФС ещё делились на те, которые поддерживают ssd и те, которые нет, дефолт не подразумевался. И поддержка trim была ключевым аргументом в пользу той или иной ФС, если не хочешь угробить SSD за пару месяцев.

А вот write ampl у разных фс разный

SSD не умеет изменять данные на месте. В итоге твоя ext4 на ssd превращается в COW ФС как и btrfs, только кривую и косую. Не понимаю чем ты тут перемогаешь?

ox55ff ★★★★★
()

хех, клоун с поршиком всё ещё чешет Даннинга с Крюгером на моем лоре

скоро в дневничке каждого штудня-клиента инфоцыган - навыки успешных людей: самоутверждаться, бравируя тупизной на форумах 🤣

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

Изменение данных на месте ни при чём. Причём то, что btrfs на юзерскую запись одного блока в среднем делает больше записей на блочное устройство чем ext4. Зачем оно это делает, какие там у неё cow или ещё что - для ссд не важно.

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

write amplification = «data written to the flash memory» / «data written by the host».

Т.е. буквально во сколько раз контроллер SSD запишет больше данных, чем попросил хост. Здесь ФС вообще не участвует. Или у тебя особое уличное определение write amplification?

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

Почему ты одно и то же явление (прислали 1 блок, записалось 5 блоков) на уровне ссд-контроллера и на уровне драйвера фс не хочешь называть одинаковым термином? Введён производителями ссд потому что для них это оказалось важно, в отличие от hdd, и умножение записей файловой системой важно точно так же.

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

Квантор общности вас кто учил применять?

Я скоро начну коллекционеровать ЛОРовские треды на тему «шеф - всё пропало, btrfs рулит». И народ настойчиво продолжает грызть кактусы…

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

Потому что на уровне ФС нет никакого «прислали 1 блок, записалось 5 блоков». ФС не может генерировать столько метаданных. Откуда столько возьмётся? Что там в этих данных? Этого не может быть в принципе, кроме как COW.

Да, BTRFS это COW, но я тебе уже выше написал, что ssd иначе физически не может работать. И у тебя COW будет на любой ФС, в том числе и на твоей любимой ext4.

Просто ты двигаешь протухшие тейки. Во времена hdd это было бы заметно, потому что ext4 работал бы без COW и на btrfs твои былинные 5x вполне могли бы нарисоваться. Но какая разница, что было в копролитическом периоде развития компьютеров. Это уже не актуально.

ox55ff ★★★★★
()
sudo smartctl -l selftest /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.3.12_1] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Conveyance offline  Completed without error       00%       856         -
# 2  Extended offline    Completed without error       00%       856         -
# 3  Short offline       Completed without error       00%       854         -
# 4  Short offline       Completed without error       00%         2         -
Dr64h ★★★
() автор топика
Ответ на: комментарий от vbcnthfkmnth123

4.2 Ещё один.

Мне тут давали скрипт, который забивает диск файлами и якобы это потом продемонстрирует невозможность удалить файлы на btrfs. Запустил, забил диск, файлы удалились нормально. Ext4 гробит данные (в том числе в Debian Stable) (комментарий)

Хватить сказки рассказывать.

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

ФС не может генерировать столько метаданных.

Ты хорошо подумал? Ну смотри:

1) записываем намерение о записи блока в журнал

2) записываем намерение о записи mtime файла в журнал

3) записываем блок

4) обновляем mtime (да, там надо обновить несколько байт, но пишем всё равно блок)

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

Во времена hdd это было бы заметно, потому что ext4 работал бы без COW и на btrfs твои былинные 5x вполне могли бы нарисоваться

ext4 не «работал бы», он всегда работает без cow. Только к btrfs это всё никакого отношения не имеет (я не знаю как ты вообще мог усмотреть связь между амплификацией btrfs и работой ext4).

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

А что принципиально поменялось?

Ты серьёзно пруфаешь протухшим на 7 лет документом? В те времена как минимум space_cache=v2 не был по умолчанию. Если вбрасываешь, то доказывай, что ничего не поменялось, а не на собеседника перекладывай.

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

Вот опять.

— Рррряяя btrfs не может удалить файл.
— Как воспроизвести? Не получается.
— Врётиии. То что лично ты не смог воспроизвести - не значит, что такого «быть не может», вот и всё.
— Пруфы где?

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

Ну смотри:

Ext4 всего этого не делает?

ext4 не «работал бы», он всегда работает без cow.

Если он на ssd, то будет физически будет COW из-за принципа ssd. Или ext4 физику записи на ssd обманет? Расскажи как.

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

вот тебе документ что может

Семилетней давности. То что ничего не изменилось это твоё манязаявление. Я как минимум привёл пример со space_cache, который сейчас по умолчание v2, а до 2021 года был v1. В твоём тухляке упоминается, что они монтируют с дефолтными параметрами. Значит там v1.

When btrfs is mounted with the default mount options

ox55ff ★★★★★
()

…в терминале начали появляться I/O Errors…

Если в этой теме кто-то что-то имеет против btrfs, смело заноси его в игнор-лист, ибо btrfs-хейтеру ненависть затуманивает мозг, и сказать что-нибудь умное он уже неспособен.

btrfs или любая другая файловая система тут совершенно не при чём. Проблема или в самом диске, или в контроллере.

У меня был случай: через какое-то время в консоли появлялись I/O error, я не мог запустить ни одного нового процесса, но уже запущенные продолжали работать. После ребута fsck находил и исправлял какие-то ошибки, но смарт-тесты (и быстрые, и медленые) не находили никаких проблем, badblocks тоже не находил ничего плохого. В конце концов выяснилось, что глючил контроллер SATA. На маме было 4 SATA-разъёма с ICH8R — с ними проблем не было, и ещё два SATA-разъёма с отдельной микрухи (под названием GIGABYTE SATA2) — вот, эта микруха и дурила. Проблема решилась покупкой SATA-контроллера (т. к. все четыре нормальных SATA-разъёма были уже заняты).

Второй случай и I/O error был связан с тем, что SATA-кабель проходил очень близко к видеокарте. Прокладка SATA-кабеля на большем расстоянии от видюхи решила проблему.

Так что для начала попробуй поменять SATA-кабель, или хотя бы просто вытащить его из разъёма и воткнуть обратно, проложить его по-другому. Посмотри доку на материнскую плату — все ли SATA-разъёмы одинаковы. Попробуй переткнуть SATA-кабель в другой разъём, или использовать другой контроллер. Если ничего не поможет — меняй диск.

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

Должен. Это ты вбросил документ-тухляк и ты же заявил, что не поменялось. Вот и доказывай. Я бы мог остановится только на указании даты. Но смилостивился и привёл пример.

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

откуда в btrfs берется бОльшее количество записей ?

write amplification у всяких btrfs/zfs на записи мелкими блоками зачастую уходит в район 10 (юзер записал 10КБ а на диск записалось 100)

no-dashi-v2 ★★★
()
Ответ на: комментарий от no-dashi-v2

write amplification у всяких btrfs/zfs на записи мелкими блоками

Это fs-independent. На таких коротких updates WAF будет запредельным по-любому.

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

Потому что на уровне ФС нет никакого «прислали 1 блок, записалось 5 блоков». ФС не может генерировать столько метаданных

LOL. Как раз на уровне ФС это все и происходит. Записать данные в новое место, запись производится только блоком аллокации - а он как правило от 8КБ, затем надо записать контрольную сумму, и контрольную сумму для контрольных сумм, и контрольнуб сумму контрольной суммы контрольны сумм - и так далее (дерево хэшей, да). Поэтому амплификация x10 на CoW это «еще нормально». Я видел и x15, и x20.

no-dashi-v2 ★★★
()
Ответ на: комментарий от MagicMirror

С моей стороны документ с измерениями

С твоей стороны не документ, а тухляк. ФС встроена в ядро. В тот момент последней версий ядра линукс была 4.12, сейчас 6.7. Что ты им пытаешься пруфать?

А что принципиально поменялось? Корова то всё та же.

Никаких доказательств, что «всё та же» я не увидел. Жду.

ox55ff ★★★★★
()