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

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

Если вначале ты хотя бы пытался пруфать старьём, то сейчас совсем скатился. Киваешь на какие-то пластинки, выкрикивания.

Я немного шокирован, что для тебя является откровением, что в ФС вносятся изменения и данные семилетней давности уже не являются точными. Это же такая банальность. Что с тобой не так? Признай, что вбросил документ, не посмотрев на дату. Там же нужно по ссылке кликать и переходить в arxiv.org, чтобы увидеть. Невыносимая сложность.

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

Через журнал прокатывается только апдейт метаданнных, но этот апдейт происходит только если он явно запрошен или происходит вытеснение из кэша или случаются ломающие изменения. И даже тогда, посккольку изменения метаданных прокатываются в журнал с синком, то собственно кэшированный блок метаданных пишется «от случая к случаю». И получается, что оно все работает 99% времени в кэше.

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

Только для коровьих ФС. Классические ФС в этом плане очень лучше себя ведут

Почему? Я фундаментальных причин не вижу.

Кстати - в случае SSD оно по определению COW, я не до конца понимаю какую роль логическая структура fs может сыграть в этом контексте.

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

данные семилетней давности уже не являются точными.

Хочешь сказать, что за эти семь лет магически изменили природу коровы? Всю эту ветку можно было бы закончить одной ссылкой, где WA отсутствует, но ты предпочитаешь разводить демагогию на ровном месте.

Признай, что вбросил документ, не посмотрев на дату

Как раз посмотрел и считаю его актуальным, даже если точные цифры поменялись в ту или иную сторону - порядок вещей не поменялся.

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

Гхм. Если мне нужно записать 50 байт - по факту будут выгружены как минимум 512, а реально все 4k. И к метаданным это никакого отношения не имеет. А если мы ещё принесём HW controllers to the picture - всё станет ещё веселее.

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

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

Да все нормально там с железом. NVMe ATI и SSD Intel
На этом железе с ext4 до перехода на это уебище все было ок.
Файлопомойку конечно сразу переформатировал назад в ext4, а системный жду оказии с плановой заменой на более емкий.
btrfs – больше никогда.

athost ★★★★★
()
Последнее исправление: athost (всего исправлений: 1)
Ответ на: комментарий от no-dashi-v2

Записать данные в новое место, запись производится только блоком аллокации - а он как правило от 8КБ

Ext4 тоже должна аллоцировать место под внутренние структуры. И точно так же на ssd это приведёт к COW всей страницы даже для малейших изменений, потому что иначе ssd не работают. На уровне диска write amplification тот же.

затем надо записать контрольную сумму, и контрольную сумму для контрольных сумм, и контрольнуб сумму контрольной суммы контрольны сумм - и так далее (дерево хэшей, да)

Это у ZFS. У btfs нет end-to-end checksums.

Поэтому амплификация x10 на CoW это «еще нормально».

Если не учитывается амплификация, которую вызывает ext4 на ssd диске из-за «COW природы» ssd, то сравнение кривое и ничего не показывает.

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

Вот когда у тебя просто на ровном месте при копировании 10Г на системный раздел с 22Г свободного места исчезнет половина конфигов в /etc, тогда ты вспомнишь этот свой пост про электрошокер)))

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

Хочешь сказать, что за эти семь лет магически изменили природу коровы?

Какой коровы? Это зумерский слэнг? Если ты про COW, то я тут уже десять раз повторил, что SSD всё равно будет COW вне зависимости от ФС. Потому что так работает ssd. Он не может произвольно изменить данные в уже записанной странице. Нужно скопировать данные в новое место. И это даёт write amplification. Просто контроллер ssd скрывает эти сложности.

Как раз посмотрел и считаю его актуальным

«я считаю» — это просто ни чем не подкреплённые манязаявления. Ты буквально утверждаешь, что ничего за 7 лет в ФС не изменилось. Хотя я привёл как минимум один пример, когда изменилась структура ФС и с 2021 года это изменение стало по дефолту. Что как раз и говорит — изменения происходят. Ты же упорно игнорируешь эти неудобные для твоей точки зрения факты.

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

Ты же упорно игнорируешь эти неудобные для твоей точки зрения факты.

@

Буквально игнорирует половину фразы, чтобы аргумент не выглядел абсурдным.

Ссылки то будут или балабол?

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

Как копировал? Может ты с правами накосячил, файлы не скопировались, а ты оригинал удалил. Виноватым назначен btrfs. Чё жалеть этого буржуя?

У меня было три глобальных переноса файлов с btrfs на btrfs. Один делал через rsync, второй раз через btrfs device add/delete и третий через btrfs send/recv. Объём 1.5 ТБ. Все успешные. Скорее всего косяк не в ФС, а что-то иное было с системой.

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

Ссылки на что? На то что за 7 лет ничего не изменилось? Так это твоя писанина и твоя же обязанность доказывать.

$ uname -a
Linux abc 6.7.0-arch3-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 Jan 2024 14:37:14 +0000 x86_64 GNU/Linux

Прошу ссылку на документ с тестированием версии btrfs из ядра 6.7. То что было в 2017 году в ядре 4.12 меня уже не интересует. Это даже не поддерживается. С тем же успехом ты мог бы привести пруф на ядро 2.6.

Так же дежурно напоминаю про появление space_cache=v2. Я вижу как ты крутишься, чтобы не замечать. Выглядит смешно. Ну заметь уже. Это не страшно. Правда-правда.

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

То что было в 2017 году в ядре 4.12 меня уже не интересует. Это даже не поддерживается.

Вы глубоко неправы. RH8 вроде как на 4.18 (с кучей патчей), и это надолго. Как раз то что происходит в 6.x - мало кого волнует.

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

Ты же упорно игнорируешь эти неудобные для твоей точки зрения факты.

Что в лоб что по лбу. Непрошибаемый просто. Ещё и наглое хамло к тому же. Цензурно продолжать с тобой «общение» я не могу.

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

RH8 вроде как на 4.18 (с кучей патчей)

Шапкопроблемы, шапкопользователей.

Как раз то что происходит в 6.x - мало кого волнует.

Ну да, на текущее состояние дел смотреть не будет, а посмотрим что там было в былинном 2007. Шапкоцентричность.

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

RH8 вроде как на 4.18 (с кучей патчей)

Шапкопроблемы, шапкопользователей.

Шапкоцентричность.

Маленькая проблема - «кто девушку поит, тот её и танцует». Нравится Вам это или нет - но диктовать «правила игры» будут именно эти люди. На всех уровнях.

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

когда в dmesg повалились ошибки именно btrfs?

Какие ошибки? Если на чексуммы, то ext4 молчит, потому что он анскильный в этом плане и молча проглатывает битые файлы.

Да все нормально там с железом. NVMe ATI

Бгг. Это не нормально. AMD не делает свои чипы памяти. Какой хлам они скупают страшно представить. У меня как раз ФС развалилась из-за битой планки ОЗУ Radeon. Не покупай память от AMD.

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

Шапка эту девушку не танцует:

Contributors
The following companies contribute to Btrfs code, not counting the treewide and other subsystem changes. Infrequent contributions are not reflected in this list, please have a look to the git history for complete list.

Sorted by amount of contributions:
SUSE
Facebook
Western Digital
Oracle

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

Без ФС, которая проверяет чексуммы, это голословное утверждение. Поменяется битик внутри файла, а ты и не заметишь. Будешь на форумах рассказывать про надёжную ext4.

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

Будешь на форумах рассказывать про надёжную ext4.

Там где это действительно нужно - хранят md5sums отдельно, не полагаясь на что там fs внутри делает. Так - мысли вслух…

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

Как твоя ненависть к сладкой горе отменяет факт отсутствия шапки в топе контрибьютеров?

Это личное. Но я и 3х-метровой палочкой трогать не буду к чему FB (нынче META) прикасались. Тем более fs.

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

Да нет, он всё правильно говорит. Write amplification у тебя будет хотя бы за счёт того, что в B-tree based FS любое изменение чего угодно — это перезапись N * tree_height + K блоков, где K — это количество суперблоков (~2-3), tree_height — это высота B-дерева (~4-5), а N — это количество различных деревьев, которые нужно обновить (в случае btrfs это минимум 4, а то и больше).

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

я решил посмотреть о чем собствено нагуглил тут что надо смотреть через смарт реальное количество записей. ну и вот я смотрю…. ничего не работает а диск сума сходит. пока этот пост писал уже 10к написалось. у меня ext4. и действительно сейчас посмотрел диск переодически моргает своим лампочкой.

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

P. S. (не дописал)

…N — это количество различных деревьев, которые нужно обновить (в reiser4 это 1, но в случае btrfs это минимум 4, а то и больше). Ну и сами данные, естественно.

Сравниваем с обычными ФС, где ты пишешь данные + один блок в block/extent map + один блок в таблицу инодов (а зачастую extent map будет inline и тогда два последних блока — это один и тот же), всё.

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

Клавиатура жива, спасибо. Но всё таки: я правильно вас услышал - ваше любимое говнище не только данные теряет, но и пишет в 4 раза больше метаданных чем конкуренты (ваши же слова)?

ПыСы: я вас даже из игнора достал, на время…

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

Любимого говнища у меня нет, не нужно проецировать на меня свои фекальные девиации, пожалуйста. Но если речь про btrfs, то у меня она ничего не теряет, а повышенный по сравнению с другими решениями write amplification — это, естественно, недостаток, о котором я отлично знаю и достаточно часто упоминаю.

я вас даже из игнора достал

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

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

Выявляем процессы с дисковой активностью в Linux

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

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

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

Делает, конечно. Так я ж говорю, что amplification есть у всех фс. У ext4 он поменьше, у btrfs - побольше.

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

Причём тут это? Амплификация не появляется магическим образом от слова «cow», она появляется от механики работы файловой системы для обеспечения этого cow именно на уровне фс. От того, что ссд внутри себя устраивает cow, файловая система cow-ой не становится.

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

И ты туда же. COW это не магическое заклинание, которое увеличивает WA. Надо смотреть механизмы, которые ради него сооружены. Да и вообще, COW в файловой системе и внутри ссд это разные COW. COW внутри ссд сделан как раз для того, чтобы ссдшное WA снизить - без него оно было бы запредельным, т.к. пришлось бы ради каждого блока перезаписывать всю страницу блоков (не знаю сколько это блоков но вполне может быть за тысячу), а так как есть - если ссд-флешка не забита до упора то WA весьма умеренное.

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

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

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

Там где это действительно нужно - хранят md5sums отдельно, не полагаясь на что там fs внутри делает.

Отдельно где, в файлах? Значит, не очень-то и нужно, если атомарность не беспокоит.

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

Ещё раз попробую объяснить.

Прога записала строчку в файл.

1) строчка превращается в блок, потому что иначе точно никак

2) файловая система превращает блок в 5 блоков

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

Итого на флешку будут записаны 10 блоков. Ты на основании того, что есть коэфициент х2 в третьем пункте, почему-то пытаешься выкинуть из рассмотрения коэфициент х5 во втором. А надо не выкидывать а перемножить их друг на друга.

firkax ★★★★★
()