LINUX.ORG.RU

BTRFS и аварийное выключение

 , , ,


0

2

Привет, ЛОР.

Рубрика успокойте паранойю.

Дано: Система с BTRFS, в которой 2 SSD диска склеены в RAID0 средствами самой ФС.

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

Сегодня в процессе сборки тяжелого Android проекта все намертво повисло, пропал звук, 0 реакции на попытки перейти в tty / REISUB, в общем, ничего не оставалось кроме как сделать аварийное выключение.

В логах после перезагрузки не нашел абсолютно ничего, даже намёков на проблему, но интересует другое.

Если btrfs device stats и scrub status выдают вот такие данные, можно ли спать спокойно?

Концепцию CoW понимаю, но пляски с fsck в ext4 в прошлом дают о себе знать, да и вообще, аварийное выключение всегда воспринималось мною как крайне опасное мероприятие.

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

➜  ~ sudo btrfs device stats / && sudo btrfs device stats /home
[/dev/nvme1n1p2].write_io_errs    0
[/dev/nvme1n1p2].read_io_errs     0
[/dev/nvme1n1p2].flush_io_errs    0
[/dev/nvme1n1p2].corruption_errs  0
[/dev/nvme1n1p2].generation_errs  0
[/dev/nvme0n1p1].write_io_errs    0
[/dev/nvme0n1p1].read_io_errs     0
[/dev/nvme0n1p1].flush_io_errs    0
[/dev/nvme0n1p1].corruption_errs  0
[/dev/nvme0n1p1].generation_errs  0
[/dev/nvme1n1p3].write_io_errs    0
[/dev/nvme1n1p3].read_io_errs     0
[/dev/nvme1n1p3].flush_io_errs    0
[/dev/nvme1n1p3].corruption_errs  0
[/dev/nvme1n1p3].generation_errs  0
[/dev/nvme0n1p2].write_io_errs    0
[/dev/nvme0n1p2].read_io_errs     0
[/dev/nvme0n1p2].flush_io_errs    0
[/dev/nvme0n1p2].corruption_errs  0
[/dev/nvme0n1p2].generation_errs  0
➜  ~ sudo btrfs scrub status / && sudo btrfs scrub status /home
UUID:             6dbfff5e-02c9-4f4e-aed7-c9e20424076b
Scrub started:    Tue Feb 17 17:24:50 2026
Status:           finished
Duration:         0:00:02
Total to scrub:   15.40GiB
Rate:             7.70GiB/s
Error summary:    no errors found
UUID:             c589e670-abd1-4b5f-bd59-92bdcc418313
Scrub started:    Tue Feb 17 17:24:56 2026
Status:           finished
Duration:         0:01:00
Total to scrub:   583.55GiB
Rate:             9.70GiB/s
Error summary:    no errors found
★★★★★

В основном там проблемы были только с raid5/6, для raid0, аварийное выключение обычно приводит к ругани на контрольную сумму в недописанном файле и недописанные данные в нём
В отличие от raid1/5/6 на raid0 не должно быть скрытых проблем т.к у него нет возмрожности проблему «скрыть» прочитав данные с других носителей

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

Так оно же вроде концептуально не может быть «недописанным».

Т.е. у нас CoW, который пишет файл в новую ячейку и потом переставляет указатель, если система рухнула в процессе записи, указатель просто останется на старой версии файла, до модификации, или я неправильно трактую?

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

Понять бы, как сопоставить теорию с практикой, в том плане, что у меня нет других инструментов, кроме scrubs и stats (либо я о них не знаю)

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

Это если диск не переставляет местами записи для оптимизации, а некоторые переставляют и может выйти что указатель он переписал, а данные всё ещё ждут своей очереди записи. Хотя если у тебя ссд то это не актуально, им переставлять местами записи смысла нет. Хотя если raid0 - две его половины могут по-ранзному успеть и опять, указатель на первом ссд записался, а второй лагнул и данные записать не успел.

Впрочем насколько правильно ты описал работу btrfs я не знаю.

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

Диски в RAID0 я по историческим причинам склеил, ранее там была Б-гомерзкая Windows и физический dual boot.

В любом случае, я пока пытаюсь понять, какие гарантии дает (и дает ли) device stats и scrub status.

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

в процессе сборки тяжелого Android проекта все намертво повисло

Зато программный, а не аппаратный raid, целого 0-го уровня, на монолитном ядре. Главное не зависнуть при вычислении криптографического (а не хухры-мухры какого) хеша.

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

Потому что raid0 это прямая противоположность тому, для чего рейды вообще сделаны. Настоящие рейды уменьшают шанс потери данных и аварийного отказа системы, raid0 наоборот увеличивает. Его применение допустимо в двух случаях:

1) ты не боишься потери данных (это временное хранилище, а raid0 чтобы хоть немного ускорить его работу)

2) тебе совершенно неизбежно требуется большой монолитный объём хранения, и нарезать его на части на более высоком уровне абстракции (в клиенте) невозможно

Никаких других оправданий его применению не может быть.

Учитывая склонность ссд (по сравнению с хдд) дохнуть резко и насовсем - ещё хуже.

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