BTRFS. Готова ли к использованию в 16.04?

[thunderamur]

thunderamur, какой-то странный эксперимент

Не проще было из /dev/urandom сделать один файл и копировать его на два разных раздела.

Не проще, сжатие заведомо тут проиграет. И это вообще бесполезный тест, т.к. я не urandom на дисках храню. 

Можно взять просто большой документ PDF.

Вообще дичь. 

Еще можно взять какой-нибудь существующий каталог (например /etc) там довольно много мелких файлов. Это будет уже не совсем тест упаковки а тест того как упаковка влияет на файловые операции в целом.

Можно.
А знаешь почему dd? Потому что если бы я читал файлы с разделов, то имел бы дело со сравнением скорости чтения ФС без сжатия и записи на ФС со сжатием, против чтения с ФС со сжатием и записи на ФС без сжатия. В случае с dd читающей не сжатый раздел я получил поток реальных данных, которые могут быть сжаты, а когда dd читала раздел со сжатыми данными, то я получал поток не сжимаемый, но для ФС без сжатия это было побоку. Что важно объем данных dd в единицу времени был одинаков в обоих случаях, т.к. ему пофиг на особенности ФС и сами данные.

Вот какой-то такой эксперимент получился. 

А дедупит BTRFS действительно мощно.

[eNdiD]

Доигрался я.

Вчера эксперименитровал с Gnome. Сегодня нужно работать, решил вернуть все как было. Для этого, я вчера зараннее сделал снимки @ и @home. Сегодня загружаюсь с live usb, монтирую диск, грохаю @ и @home и переименовую в них @_bak и @home_bak. Все как и раньше, проблем никаких не ожидалось. Делаю umount, перезагружаю иии. Система виснет. Ну я думаю, ну и пусть. Вытаскиваю флешку, делаю хард ребут. И вижу, что grub побит. Я гружусь опять с live-usb, монтирую раздел и вижу картину: @_bak и @home_bak так и остались не переименованы. Я опять повторяю переименование. Отмонтирую. Система опять виснет. Все то же самое.

Короче говоря система зависает через некоторое время при попытке примонтировать этот раздел с btrfs. Виснет даже если пытаюсь примонтировать с -o recovery. При этом в dmesg никаких ошибок нет, если успеть глянуть до зависания. То есть, раздел монитруется, выдается парочка info сообщений и все. Пытался снять образ метаданных с помощью btrfs-image:

(Нажмите, чтобы показать/скрыть)

checksum verify failed on 109525037056 found E7B96D00 wanted 00013CCE
checksum verify failed on 109525037056 found E7B96D00 wanted 00013CCE
bytenr mismatch, want=109525037056, have=13849131797419321567
Error reading metadata block
Error adding space cache blocks -5
checksum verify failed on 109525037056 found E7B96D00 wanted 00013CCE
checksum verify failed on 109525037056 found E7B96D00 wanted 00013CCE
bytenr mismatch, want=109525037056, have=13849131797419321567
Error reading metadata block
Error flushing pending -5
create failed (Success)

Дела плохи.

Спойлер: перенести снимок на другой диск мне видимо религия не позволила. А раньше всегда делал. ССЗБ.
Да, это SSD. SMART в полном порядке.

Работа стала, пойду гуглить. Я даже не знаю, с чего начинать пробовать восстановление. Как мне сейчас сделать резервный снимок раздела без монтирования? А то почитал вики, написано, что можно и угробить то что осталось, если не правильно восстанавливать.
Пользователь добавил сообщение 11 Апреля 2017, 11:15:42:Вывод btrfs check:

(Нажмите, чтобы показать/скрыть)

Checking filesystem on /dev/sda2
UUID: df0c8954-9602-465f-82ac-b5039aecbcf0
checking extents
corrupt extent record: key 109524959232 168 77824
corrupt extent record: key 109525037056 168 81920
corrupt extent record: key 109525118976 168 81920
corrupt extent record: key 109525200896 168 98304
corrupt extent record: key 109525299200 168 94208
ref mismatch on [109524873216 86016] extent item 16898097290397089221, found 1
ref mismatch on [109524959232 77824] extent item 16951580881043191694, found 1
Backref 109524959232 root 460 owner 5227682 offset 6684672 num_refs 0 not found in extent tree
Incorrect local backref count on 109524959232 root 460 owner 5227682 offset 6684672 found 1 wanted 0 back 0x28292a0
backpointer mismatch on [109524959232 77824]
ref mismatch on [109525037056 81920] extent item 5213254701863807789, found 1
Backref 109525037056 root 460 owner 5227682 offset 6946816 num_refs 0 not found in extent tree
Incorrect local backref count on 109525037056 root 460 owner 5227682 offset 6946816 found 1 wanted 0 back 0x4d25c90
backpointer mismatch on [109525037056 81920]
bad metadata [109525037056, 109525118976) crossing stripe boundary
bad extent [109525037056, 109525118976), type mismatch with chunk
ref mismatch on [109525118976 81920] extent item 14857125596567025771, found 1
Backref 109525118976 root 460 owner 5227682 offset 7340032 num_refs 0 not found in extent tree
Incorrect local backref count on 109525118976 root 460 owner 5227682 offset 7340032 found 1 wanted 0 back 0x5d99220
backpointer mismatch on [109525118976 81920]
bad metadata [109525118976, 109525200896) crossing stripe boundary
bad extent [109525118976, 109525200896), type mismatch with chunk
ref mismatch on [109525200896 98304] extent item 7905649980062840434, found 1
Backref 109525200896 root 460 owner 5227682 offset 7471104 num_refs 0 not found in extent tree
Incorrect local backref count on 109525200896 root 460 owner 5227682 offset 7471104 found 1 wanted 0 back 0x1144570
backpointer mismatch on [109525200896 98304]
Backref 109525299200 root 460 owner 5227682 offset 7602176 num_refs 0 not found in extent tree
Incorrect local backref count on 109525299200 root 460 owner 5227682 offset 7602176 found 1 wanted 0 back 0x2829170
backpointer mismatch on [109525299200 94208]
checking free space cache
checking fs roots
checking csums
checking root refs
found 31646085232 bytes used err is 0
total csum bytes: 29957896
total tree bytes: 937000960
total fs tree bytes: 845692928
total extent tree bytes: 50610176
btree space waste bytes: 189405528
file data blocks allocated: 45980393472
 referenced 42949767168

Пользователь добавил сообщение 11 Апреля 2017, 11:31:50:Дальше по очереди, что я пытался сделать:

sudo btrfs rescue zero-log /dev/sda2:

(Нажмите, чтобы показать/скрыть)

Clearing log on /dev/sda2, previous log_root 0, level 0

sudo btrfs rescue chunk-recover /dev/sda2

(Нажмите, чтобы показать/скрыть)

Scanning: DONE in dev0                       
Check chunks successfully with no orphans
Chunk tree recovered successfully

sudo btrfs rescue super-recover /dev/sda2

(Нажмите, чтобы показать/скрыть)

All supers are valid, no need to recover

Сейчас сделаю копию через btrfs restore и пойду дальше пытаться.
Пользователь добавил сообщение 11 Апреля 2017, 11:54:18:Отработало btrfs restore. Ошибок вроде нет, визуально восстановленные данные обоих подтомов @_bak и @home_bak выглядят нормально. Потыкал по директориям, пооткрывал файлы - все ок. Правда, в процесее выдавало несколько сообщений вида:

(Нажмите, чтобы показать/скрыть)

We seem to be looping a lot on /some/file/name, do you want to keep going on ? (y/N/a):

Отвечал стандартное N. Сообщение выдавало только для кеша и файловол лога, думаю, это совершенно некритично.

Теперь как минимум, есть возможность попытаться отформатировать раздел, создать вручную подтома и все скопировать, если btrfs check все испортит.

[Vikonrob]

у меня на BTRFS стабильно перестает загружаться буунта при следующих условиях:

1. Устанавливаем с нуля Ubuntu на SSD c FS BTRFS
2. Всё установилось, работаем, настраиваем под себя.
3. Загружаемся в Live CD Filezilla, делаем образ SSD-диска.
4. загружаемся снова в Ubuntu, работаем неделями, месяцами.
5. Вдруг захотелось восстановить образ, который делал на 3-м пункте файлзиллой
6. Загружаемся в Live CD Filezilla, восстанавливаем образ.
7. Загружаемся в восстановленную из образа Ubuntu. Снова работаем, как ни в чем не бывало до первого срабатываения команды трим
8. Происходит срабатывание TRIM по крону (который прописан в /etc/cron.weekly/fstrim), трим отрабатывает, работаем дальше до первой перезагрузки.
9. Перезагрузка и.. черный экран

Если не восстанавливать ранее сохраненный образ клонзиллой, то TRIM отрабатывает, и дальше проблем с загрузкой никаких нет.

Вышеописанной проблемы не наблюдается с ФС ext4.
Что такого клонзилла портит в разметке, что потом трим валит btrfs так и не разобрался.

[eNdiD]

Запустил btrfs check --repair. Ошибки починились. Удалось смонтировать раздел и переименовать подтома. Система загрузилась и вроде все хорошо. Мроль: все как обычно. Бэкапы и все такое. И не надеятся, как я, на то, что в этот раз все пройдет точно так же, как и в прошлый.

P.S. Может стоит добавить в wiki информацию по btrfs restore?

Vikonrob,
может вы имеете в виду Clonezilla? btrfs хорош тем, что клонзилла не нужна. Сделали снапшот и отправили куда нужно через btrfs send | receive. Это даже быстрее будет.

[Sly_tom_cat]

Vikonrob, TRIM - это команда интерфейса между диском и ФС. На диске вы поменяли все при восстановлении - только об этом диск не знает (а должен). В результате идет рассинхрон между тем что занятым считает ФС и диск.
Пользователь добавил сообщение 11 Апреля 2017, 12:15:40:eNdiD, там уже отдельный раздел про восстановление есть: https://help.ubuntu.ru/wiki/btrfs#восстановление_btrfs и вам никто не мешает добавить, а с учетом полученного вами опыта - лучше бы вам это туда и приписать с пояснениями.

[Vikonrob]

На диске вы поменяли все при восстановлении - только об этом диск не знает (а должен). В результате идет рассинхрон между тем что занятым считает ФС и диск.

Вот теперь понятно. Спасибо за внятный ответ!

[Sly_tom_cat]

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

[Vikonrob]

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

Увы, проверить смогу только тогда, когда вновь найдет на меня "бзик", и я снова всю систему переустановлю на BTRFS. Пока сижу на EXT4.

[Sly_tom_cat]

Vikonrob, так можно же на виртуалке.

[Vikonrob]

Sly_tom_cat, а на виртуалке сработает трим? Там же не SSD, а виртуальный диск Попробую.

[Venom13]

Походу мой многодисковый массив накрывается.

Недавно меня вдруг стало напрягать сообщение "raid56 detected not implemented".
В связи с тем, что постепенно на массиве стали накапливаться данные,
которые бы уже не хотелось терять, решил сконвертировать ВСЕ ЭТО в RAID1.
(RAID10 отмел, т.к. диски очень разных размеров, и будут вечно падать в "закончелось место на массиве").

Так вот. Запустил я конвертацию:

Код: [Выделить]

sudo btrfs balance start -mconvert=raid10 -sconvert=raid10 -dconvert=raid1 -f -dsoft /mnt/root/
И пошел спать.
Утром увидел что операция упала с ошибкой, и получил вот такое состояние дисков:

(Нажмите, чтобы показать/скрыть)

Первое что пришло в голову - нехватка места. Удалил нахрапом с 500Gb фильмов, и запустил повторно...
Через несколько часов опять упало.
Полез разбираться..

В логе dmesg | tail вижу:

Код: [Выделить]

[ 2456.035980] BTRFS info (device sdb): relocating block group 12828256763904 flags metadata|raid10
[ 2527.176586] BTRFS info (device sdb): found 38134 extents
[ 2527.763834] BTRFS info (device sdb): relocating block group 12827183022080 flags metadata|raid10
[ 2652.459401] BTRFS info (device sdb): found 40505 extents
[ 2653.575106] BTRFS info (device sdb): relocating block group 6055274741760 flags data|raid5
[ 2663.293288] BTRFS warning (device sdb): csum failed ino 261 off 1556783104 csum 1398170721 expected csum 1822731586
[ 2663.294823] BTRFS warning (device sdb): csum failed ino 261 off 1556783104 csum 1398170721 expected csum 1822731586
[ 2663.355512] BTRFS warning (device sdb): csum failed ino 261 off 1556783104 csum 1398170721 expected csum 1822731586
[ 2663.362772] BTRFS warning (device sdb): csum failed ino 261 off 1556783104 csum 1398170721 expected csum 1822731586
[ 2663.363023] BTRFS warning (device sdb): csum failed ino 261 off 1556783104 csum 1398170721 expected csum 1822731586

Ага! sdb побит..
Дальше по порядку:

Код: [Выделить]

sudo btrfs check --repair /dev/sdb
sudo btrfs check --check-data-csum /dev/sdb
Результата нет. "Все хорошо, ошибок не нашли.."

Последняя надежда:

Код: [Выделить]

sudo btrfs check --init-csum-tree --init-extent-tree /dev/sdb
И вуаля! Через 16 часов работы падает в:

Код: [Выделить]

Creating a new CRC tree
enabling repair mode
Checking filesystem on /dev/sdb
UUID: bf4afb75-e2b2-43c7-9d60-2e5c1d74791e
Creating a new extent tree
Failed to find [12867985211392, 168, 16384]
btrfs unable to find ref byte nr 12868418043904 parent 0 root 1  owner 1 offset 0
Failed to find [12867985211392, 168, 16384]
btrfs unable to find ref byte nr 12868420665344 parent 0 root 1  owner 0 offset 1
Reinitialize checksum tree
extent-tree.c:2703: btrfs_reserve_extent: BUG_ON `ret` triggered, value -28
btrfs(+0x47bc9)[0x555c24809bc9]
btrfs(+0x47c39)[0x555c24809c39]
btrfs(+0x47c4c)[0x555c24809c4c]
btrfs(btrfs_reserve_extent+0x76a)[0x555c2480df96]
btrfs(btrfs_alloc_free_block+0x63)[0x555c2480e1a1]
btrfs(+0x419db)[0x555c248039db]
btrfs(btrfs_search_slot+0x416)[0x555c24804537]
btrfs(btrfs_csum_file_block+0x24f)[0x555c24812fca]
btrfs(+0x10801)[0x555c247d2801]
btrfs(cmd_check+0xf72)[0x555c247f2d07]
btrfs(main+0x139)[0x555c247d983e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f386fb733f1]
btrfs(_start+0x2a)[0x555c247d987a]
Аварийный останов (стек памяти сброшен на диск)

При этом при на использование данных это никак не сказывается.
Может, конечно, на битые данные пока просто не натыкался..
Кто что подскажет?

[Sly_tom_cat]

Venom13, если честно, то не понял ничего что вы там наворотили....

На будущее. Конвертировать модель хранения данных можно начинать только если ФС в корректном состоянии (без проблем). Если там контрольные сумма или что еще окривело, то сначала ФС надо в норму привести, а уже потом конвертировать модель хранения.

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

[Venom13]

На будущее. Конвертировать модель хранения данных можно начинать только если ФС в корректном состоянии (без проблем).

Так и было.
Ошибки посыпались в процессе конвертации.

Теперь, боюсь, единственный путь - спасать данные и переразмечать заново.

Спасать там нечего.
Во первых - все работает. Как на чтение так и на запись.
Во вторых - там только фильмы с торрентов и тестовые виртуалки..

Поэтому можно экспериментировать.
Пользователь добавил сообщение 21 Апреля 2017, 16:34:54:

А так у вас сначала ошибки сыпались странные,

или Вы про это:

Недавно меня вдруг стало напрягать сообщение "raid56 detected not implemented".

Так это не ошибка.
Такая строчка выводится всегда, если выполнить:

Код: [Выделить]

btrfs filesystem usage <point>Если в точке монтирования присутствует модель RAID5 или RAID6..
Это отказ от ответственности. Что эти режимы не до конца доделаны,
и теоретически могут не восстановиться при выходе из строя одного диска..

[Pakostnik]

Устанавливал на посмотреть OpenSUSE - по умолчанию уже предлагается btrfs. Интересно. Они в неё верят?

[Venom13]

Интересно. Они в неё верят?

Почему нет?
Если не играться с "экспериментальными возможностями" - то все стабильно.
Пользователь добавил сообщение 12 Мая 2017, 17:25:24:Уже и в коммерческих решениях активно применяют:
https://www.synology.com/ru-ru/dsm/Btrfs