BTRFS - грабли. cat/copy/rsync = Input/Output Error (Решено)

Btrfs RAID5/6 не готов, увы.

Впрочем, даже он не должен рассыпаться на ровном месте. Лично у меня массив с RAID5 жил лет пять, ни единого разрыва. Повезло, конечно, но факт остаётся фактом.

Единственная операция, которую я еще не сделал:

btrfs balance start -mconvert=raid1 -sconvert=raid1 /data

Стоит оно того? (копию данных сделал)

RAID1 — норм. Но операцию balance нельзя запускать на ФС с неисправленными повреждениями. Сначала добейся, чтобы btrfs scrub проходил без любых ошибок, потом балансируй на raid1.

Вообще 5-й рэйд это про скорость.

Я не специалист в raid5 (почему нет резервной копии данных), но появление битых файлов в btrfs в большинстве случаев вызвано битой оперативной памятью. Попытаться восстановить файл можно прогой, которая читает по 4К блокам и игнорит ошибки (кажется можно простой dd), т.е. при доступе простой командой типа ‘cat’ произойдёт ошибка чтения всего файла, а с dd можно восстановить всё, кроме одного (или нескольких) битых секторов (где data checksum не сходится с data). Насколько я помню у btrfs scrub есть опция занулить испорченные сектора (если нет резервной копии, то они как бы уже потеряны) - т.е с помощью этой команды данные приводятся к такому состоянию, чтобы не было checksum error.

Почему счётчики corruption_errs видит только btrfs и они живут своей жизнью?

Не совсем понятен вопрос. Счётчики регистрируют количество обращений к битому сектору файла. Если есть 1 битый сектор и 100 обращений к нему, то счётчик будет показывать 100.

Во! Спасибо за пояснение. Я думал, что corruption_errs - это число попыток записи или перезаписи данных/чексумм. Если это количество чтений - то ситуация проясняется, хотя нафига считать чтения?… Вопрос риторический.

dd я как раз применил - успешно, но долго и нудно, а главное - медленно (я с zip файлом мучался). Занулить ошибски с помощью флага scrub - сейчас попробую.

Насколько я помню у btrfs scrub есть опция занулить испорченные сектора

Нет такой опции.

Хмм … значит это в btrfs check, но в текущей версии не вижу опции исправить - есть только опция проверки. Раньше была опция ‘–fix-crc’, но её сейчас уже нет.

Запустил:

btrfs check --init-csum-tree /dev/disk/by-label/RAID5

Идут вторые сутки, но что-то шевелится:

owner ref check failed [1955053568 16384]
repair deleting extent record: key [1955053568,169,0]
Repaired extent references for 1955053568
ref mismatch on [1955069952 16384] extent item 1, found 0
backref 1955069952 root 7 not referenced back 0x5575aa7e0c60
incorrect global backref count on 1955069952 found 1 wanted 0
backpointer mismatch on [1955069952 16384]
owner ref check failed [1955069952 16384]
repair deleting extent record: key [1955069952,169,0]

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

Btrfs к скорости никакого отношения не имеет.

Не могу с этим согласиться. Еще как имеет! restore/rsync скопировал диск менее чем за сутки. На текущий момент (3-и сутки) btrfs что-то выполнила на 50-60%

Длинная статья, почему с btrfs рейдом лучше не связываться: https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/

Спасибо. Я нашёл статью еще лучше, где описаны все косяки и подводные камни btrfs в деталях:

https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@hungrycats.org/

Вот и думай после этого - зачем вообще выкатили btrfs в сыром виде и превратили пользователей в бета-тестеров…

Последние сведения: моя btrfs «правила ошибки» и «пересчитывала чек-суммы» почти трое суток. Результат: все correction_errs - на месте, файлы не читаются.

# btrfs device stat /data

[/dev/sdd].write_io_errs    0
[/dev/sdd].read_io_errs     0
[/dev/sdd].flush_io_errs    0
[/dev/sdd].corruption_errs  9
[/dev/sdd].generation_errs  0
[/dev/sde].write_io_errs    0
[/dev/sde].read_io_errs     0
[/dev/sde].flush_io_errs    0
[/dev/sde].corruption_errs  6
[/dev/sde].generation_errs  0
[/dev/sdf].write_io_errs    0
[/dev/sdf].read_io_errs     0
[/dev/sdf].flush_io_errs    0
[/dev/sdf].corruption_errs  47
[/dev/sdf].generation_errs  0

Т.е. неделю (!) btrfs колбасила по-всякому три трёхтерабайтных диска из массива, который не разрушился, то прибавляя то убавляя свои ошибки, всё время сообщала «no error found», и в итоге я имею то же что в самом начале - целенький массив, 7 битых файлов и запись поверх поврежденного состояния. Я офигеваю от такой результативной работы btrfs и главное от

# btrfs check --repair /device

который фактически просто сливал время в /dev/null

Теперь я вынужден еще немного напрячься - поковырять dd для оставшихся шести файлов (просто из интереса) и потом, наверное, обнулить массив целиком и создать его заново… Мда.

переходи на ядерный ntfs3

А потому что не нужно рандомно запускать команды, отдалённо напоминающие правильные.

btrfs «правила ошибки» и «пересчитывала чек-суммы» почти трое суток

Ничего из того, что ты назапускал, не предполагает «пересчёт чек-сумм».

А вот это? (было выше)

btrfs check --init-csum-tree /dev/disk/by-label/RAID5

man btrfs-check:

--init-csum-tree
  create a new checksum tree and recalculate checksums in all files

Рандомно команды никто не запускал: всего 14 шагов от начала было сделано (детали сократил):

1# rsync ....  -> Input/Output Error
2# btrfs device usage /data
3# btrfs device stat /data
4# btrfs scrub start -Bdr /data -> Unrecoverable errors
5# mount -o remount,ro,recovery,nospace_cache,clear_cache /data
6# btrfs check --check-data-csum -p /dev/disk/by-label/RAID5
7# journalctl --dmesg --grep 'checksum error'
8# btrfs rescue chunk-recover /dev/disk/by-label/RAID5 -> Freeze
9# smartctl -t long /dev/sd[def]; smartctl -a /dev/sd[def] -> No errors
0# btrfs device stat /data
1# btrfs restore /dev/disk/by-label/RAID5 /mnt/usbdisk
2# rsync --dry-run ... /data /mnt/usbdisk
3# btrfs check --repair /dev/disk/by-label/RAID5 -> No errors
4# btrfs check --init-csum-tree /dev/disk/by-label/RAID5 -> No errors
5# cp/cat/rsync ->...no results...Input/Output Error

Есть какой-то более изысканный вариант ремонта btrfs?

Ах, да - перед шагом 13# - я успешно снял битые файлы с помощью dd - но это к btrfs не относится.

три трёхтерабайтных диска

Лучше бы сделал ZFS RAIDZ.

Про ZFS я с самого начала написал. Знаю. Мой пример - яркое подтверждение, что ZFS гораздо более стабильна и предсказуема, чем BTRFS. Пока всё работает - они «типа одинаково похожи». Но когда встречаются реальные трудности - BTRFS хочется закопать.

А вот это?

Да, ты прав. Мне казалось, что в мане про неё было написано другое.

В любом случае, в мане также написано «не юзайте эту команду, чтобы избавиться от ошибок чексумм».

Есть какой-то более изысканный вариант ремонта btrfs?

btrfs restore и пересоздать том с нуля. Как в ZFS (только у них даже restore нет, там просто «ERROR: pool cannot be imported. Recommended solution: destroy pool and restore from backups», лол).

Короче - можно пометить «РЕШЕНО»… Хотя решение из двух шагов - тупое, мне не нравится (Из-за битого мегабайта я два с половиной терабайта должен гонять туда-сюда).

Решение:

Step 1: btrfs restore (+rsync)
Step 2: recreate btrfs from scratch

Важно (recreate):

# mkfs.btrfs -L data -m raid1 -d raid5 -f /dev/sda /dev/sdb /dev/sdc ...

Для raid56 - в btrfs только так.

Ну и если у кого-то диск выпал из массива то обязательно:

# btrfs replace
# btrfs balance

Потому что сама btrfs баланс не делает и работает, как будто он ей не нужен (втихаря).

Погоди. А ты raid5 для метаданных использовал, что ли?

Да, но лучше б ты сразу написал что я лошара :))))))))))))))) Хотя 3 года эта тема прокатывала :))))))))))

И мой фокус выровнять сейчас мету как надо

btrfs balance start -mconvert=raid1 -sconvert=raid1 /data

не взлетел.

По-хорошему: в mkfs.btrfs могли бы и предупреждение выдать (что комбинация raid5-raid5 хреновая/сопливая/неустойчивая). А так получается - можно сделать дурь, которая работает, но только до поры до времени…а потом превращается в тыкву. Это ж теперь с самого начала очевидно.

А почему не взлетел? btrfs balance start -mconvert=raid1,soft -f /data, вроде должно работать.

По-хорошему: в mkfs.btrfs могли бы и предупреждение выдать (что комбинация raid5-raid5 хреновая/сопливая/неустойчивая)

Да. Согласен.

В последних версиях выдают предупреждение при использовании RAID5/6 в принципе:

$ mkfs.btrfs -m raid5 -d raid5 test1 test2 test3
btrfs-progs v5.14.2
See http://btrfs.wiki.kernel.org for more information.

WARNING: RAID5/6 support has known problems is strongly discouraged
         to be used besides testing or evaluation.
<...>

Потому что

[/dev/sdd].corruption_errs  9
[/dev/sdf].corruption_errs  47

не сбрасываются ничем и от btrfs balance ничего хорошего не ожидается (но можно попробовать ради интереса)

не сбрасываются ничем

btrfs device stats -z же.

от btrfs balance ничего хорошего не ожидается

Не распарсил. Почему?

Да. Поехало, но опять не туда

# btrfs device stats -z /data
# btrfs balance start -mconvert=raid1 /data
# btrfs device usage /data

/dev/sdd, ID: 1
   Device size:             2.73TiB
   Device slack:              0.00B
   Data,RAID5/3:            1.06TiB
   Metadata,RAID1:          8.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             1.66TiB

/dev/sde, ID: 2
   Device size:             2.73TiB
   Device slack:              0.00B
   Data,RAID5/3:            1.06TiB
   Metadata,RAID1:          8.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             1.66TiB

/dev/sdf, ID: 3
   Device size:             2.73TiB
   Device slack:              0.00B
   Data,RAID5/3:            1.06TiB
   Metadata,RAID1:          8.00GiB
   System,RAID1:           64.00MiB
   Unallocated:             1.66TiB

# btrfs device stat /data

[/dev/sdd].write_io_errs    0
[/dev/sdd].read_io_errs     0
[/dev/sdd].flush_io_errs    0
[/dev/sdd].corruption_errs  9
[/dev/sdd].generation_errs  0
[/dev/sde].write_io_errs    0
[/dev/sde].read_io_errs     0
[/dev/sde].flush_io_errs    0
[/dev/sde].corruption_errs  6
[/dev/sde].generation_errs  0
[/dev/sdf].write_io_errs    0
[/dev/sdf].read_io_errs     0
[/dev/sdf].flush_io_errs    0
[/dev/sdf].corruption_errs  47
[/dev/sdf].generation_errs  0

Ошибки после обнуления и балансировки - на месте. Хотя метаданные преобразовались (на удивление очень-очень быстро).

Поясню на своём примере, почему я не ждал ничего хорошего от balance.

Во-первых, он выполнился слишком быстро - за секунды мои метаданные превратились из «Metadata,RAID5» в «Metadata,RAID1». Это означает, что BTRFS ничего не делала - просто заголовки поменяла (которые, видимо, будут действительны для новых записей).

Во-вторых, первый же btrfs scrub после балансировки и конвертации привёл к тому, что:

Error summary:    read=32 csum=4
  Corrected:      0
  Uncorrectable:  32
  Unverified:     0
...

/dev/sdd, ID: 1
   Device size:             2.73TiB
   Device slack:              0.00B
   Data,RAID5/3:            1.06TiB
   Metadata,RAID1:          8.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             1.66TiB

/dev/sde, ID: 2
   Device size:             2.73TiB
   Device slack:              0.00B
   Data,RAID5/3:            1.06TiB
   Metadata,RAID1:          8.00GiB
   Unallocated:             1.66TiB
...

Это как? На одном диске (sdd) есть системные записи, а на другом (sde) - нет? Это уже raid1 или еще raid5? :-) Бред какой-то.

И ошибок - столько же, сколько на старте…

Так что только

# wipefs --all ...

и всё заново.

С радостью докладываю: источник всей этой дичайшей ситуации найден!

Причина всего: memory fault (memtest86, test: 7,8) high address

Т.е. в четвертом банке памяти в верхних адресах памяти был сбой. Он никак не проявлял себя вообще, когда память была хоть чуть-чуть свободна. Но когда я забивал всю память виртуалками - вот тогда, случайно и очень иногда, встречались редкие ошибки записи, которые btrfs проглатывала без запинки.

Эта фигня обнаружена на новом чистом диске с btrfs как раз в тот момент, когда я в очередной раз занял всю память приложениями, записал один огромный файл (50Гб) и проверил его на чтение (и получил Input/Output error).

Не могу не отметить, что btrfs своими «показателями» серьезно сбила меня с толку, и, в общем, подлила масла в огонь: ее поведение было не идеально. Но вся информация на текущий момент цела, и теперь, наконец-то, я начинаю возвращать ее на место!

Старое доброе, начинаются непонятные глюки с данными, проверь хард, проверь мозги. :)

Вообще 5-й рэйд это про скорость.

Чего, чего?

Того-того

Последние сведения: моя btrfs «правила ошибки» и «пересчитывала чек-суммы» почти трое суток. Результат: все correction_errs - на месте, файлы не читаются.

Т.е. неделю (!) btrfs колбасила по-всякому три трёхтерабайтных диска

и в итоге я имею то же что в самом начале

Теперь я вынужден еще немного напрячься

А я ведь давненько предупреждал почтенную публику - держитесь от этого сырого гомна подальше. Так ведь не слушает же никто…

Того-того

УмнО. Многословно. Тезисно. Идите обратно «в ясли».

Извините, но я думаю, что эта статья про BTRFS тоже должна быть здесь:

https://habr.com/ru/post/559014/

Актуальность информации: май 2021 г

Эдуард Шишкин:

Как я для себя позиционирую Btrfs? Как нечто, что именоваться файловой системой категорически не может, не говоря уже об использовании. Ибо по определению ФС - это подсистема ОС, ответственная за эффективное управление ресурсом «дисковое пространство», чего в случае c Btrfs мы не наблюдаем. Ну, представьте, что вы пришли в магазин купить часы, чтобы не опаздывать на работу, а там вместо часов вам впарили электрогриль с таймером на 30 минут максимум. Так вот - с Btrfs ситуация ещё хуже.