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

[Sly_tom_cat]

Со смонтированной ФС ничего не сделаешь - она же в RO режиме.
Потерянные файлы - не удалить.
Не удается ни remove device missing, ни delete device /dev/loop1.
Перебалансировка тоже не идет на RO файловой системе.
Добавить новый девайс (пустой) - тоже нельзя

т.е. пока с починкой - тупик 

Пользователь добавил сообщение 23 Января 2017, 21:11:42:Переходим к тяжелой артиллерии:

Монтирую с -o recovery - облом.
Монтирую с -o recovery,degraded - облом.
Монтирую с -o recovery,degraded,ro - получилось!!! но файлы на месте и ничего визуально не изменилось - рекавери похоже - "ну не сшмогла я" 

[Pilot6]

Sly_tom_cat,
Я патч в сети видел, чтобы можно было чинить. Но это слишком имхо ядро для этого патчить.

Ну хотя бы так. Файлы забрать, а потом просто пересоздать.

[Sly_tom_cat]

Переходим к еще более тяжелому вооружению...

$ sudo btrfs rescue chunk-recover /dev/loop0
Scanning: DONE in dev0                     
open with broken chunk error
Chunk tree recovery failed

Облом

$ sudo btrfs rescue super-recover /dev/loop0
All supers are valid, no need to recover

Типа и так все хорошо. Ну оно и естественно ибо суперблок - он на каждом девайсе свой создается.

$ sudo btrfs rescue zero-log /dev/loop0
warning, device 2 is missing
warning devid 2 not found already
Clearing log on /dev/loop0, previous log_root 0, level 0
Unable to find block group for 0
extent-tree.c:289: find_search_start: Assertion `1` failed.
btrfs[0x438110]
btrfs(btrfs_reserve_extent+0x70b)[0x43c31e]
btrfs(btrfs_alloc_free_block+0x63)[0x43c5ae]
btrfs(__btrfs_cow_block+0x100)[0x430792]
btrfs(btrfs_cow_block+0x93)[0x430d3b]
btrfs[0x434cc4]
btrfs(btrfs_commit_transaction+0xb5)[0x436519]
btrfs[0x42950c]
btrfs(main+0x139)[0x40ec30]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fb93ddab830]
btrfs(_start+0x29)[0x40ec69]
Обна - тут пожоже btrfs вообще в осадок выпала 

Пробуем btrfs restore (т.е. уже самое мощное, что есть) пробую перезаписать файлы игнорируя ошибки:
$ sudo btrfs restore -oi /dev/loop0 .
warning, device 2 is missing
warning devid 2 not found already
Exhausted mirrors trying to read
Error copying data for ./VID_20140921_194528.3gp
Exhausted mirrors trying to read
Error copying data for ./VID_20160102_131639.3gp
Exhausted mirrors trying to read
Error copying data for ./VID_20160229_214007.3gp
Exhausted mirrors trying to read
Error copying data for ./VID_20160320_120347.3gp
... что-то вроде сделалось, но монтирование опять возможно только с degraded и RO 
Зато тут нам четко показали каким файлам полный кирдык.

... пока мысли кончились: что еще можно сделать...

Собственно спасти файлы (они же доступны в РО режиме) и пересоздать файловую систему - это конечно решение.

Но вот починить - пока не удается...

[Pilot6]

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

[Sly_tom_cat]

Вот какие мысли возникли по пути домой:
По сути то, что дисков осталось меньше чем установлено лимитом на данный тип хранения, то данные уже побиты и действительно логично не давать монтировать такую ФС в режиме разрешенной записи. А без этого та половина средств, что позволяет чинить деградированные массивы - не работает (они чинятся только на смонтированной файловой системе).
Средства же восстановления/починки ФС нацелены немного на другие задачи. Собственно уже то, что часть файлов нормально доступна на смонтированной (в RO) файловой системе это говорит, что сама то ФС "в меру здорова", а потому чинить там особо и нечего (из того что доступно - все цело, а чего нет - то и не починишь).

Однако хотелось бы понять еще вот какой момент: а что будет с порушенным RAID0 массивом?
То что на нем будут отсутствовать половина блоков в каждом файле - это понятно. Но вот я не уверен что файл размером один байт можно будет записать по частям на два диска, а значит такой файл, с вероятностью 1/2 сохранится. А если 2 байта? Наверно тоже 1/2.... а три?

Вот какой есть план - записать на RAID0 файлы (по нескольку штук) размером 1,2,3,4,5.... байтов, и разрушив массив попробовать прочитать начиная с меньших. Так можно будет установить максимальный размер файла который может выжить на RAID0.

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

[Дмитрий Бо]

Pilot6, Sly_tom_cat, спасибо! Я не ждал такого мощного ответа
У меня диски на самом деле не диски, а тома с разных хранилок. Вряд ли хранилка внезапно сломается, скорее, временно отвалится (пропадёт связь или электричество), а потом вернётся обратно. В этом случае переключение в RO выглядит разумным вариантом, т. к. теоретически после оживания второго диска можно нормально продолжить работу (без ребилдов, потери данных и пр.). Как на практике - надо будет потестить.

[Sly_tom_cat]

Дмитрий Бо, Да, именно так и есть: подцепил обратно второй образ и все нормально монтируется и все файлы доступны (несмотря на мои тщетные потуги как-то починить обрубок ФС).

Пользователь добавил сообщение 24 Января 2017, 11:41:51:Кстати проделал еще обратный финт - убрал первый образ - смонтировался (с degraded,ro) со второго образа.

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

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

Получил вот такую картину по целостности файлов:
-rw-r--r-- 1 stc  stc    3469303 июн 16  2013 IMG_20130616_140446826.jpg
-rw-r--r-- 1 stc  stc    2910487 июн 16  2013 IMG_20130616_160626809.jpg
-rw-r--r-- 1 stc  stc    3319447 июн 16  2013 IMG_20130616_160659160.jpg
-rw-r--r-- 1 stc  stc    3052087 июн 16  2013 IMG_20130616_164044061.jpg
-rw-r--r-- 1 stc  stc    1753079 июн 17  2013 IMG_20130617_124001331.jpg
-rw-r--r-- 1 stc  stc    2217783 ноя 23  2013 IMG_20131123_174929747.jpg
-rw-r--r-- 1 stc  stc    2377527 янв  5  2014 IMG_20140105_123655764.jpg
-rw-r--r-- 1 stc  stc    2355255 янв  5  2014 IMG_20140105_124246399.jpg
-rw-r--r-- 1 stc  stc    2228791 янв  5  2014 IMG_20140105_182451773.jpg
-rw-r--r-- 1 stc  stc    2350519 янв  5  2014 IMG_20140105_182748495.jpg
-rw-r--r-- 1 stc  stc    5885735 сен 21  2014 VID_20140921_194523.3gp
-rw-r--r-- 1 stc  stc  441913794 сен 21  2014 VID_20140921_194528.3gp
-rw-r--r-- 1 stc  stc  209257382 янв  2  2016 VID_20160102_131639.3gp
-rw-r--r-- 1 stc  stc  379657484 мар  1  2016 VID_20160229_214007.3gp
-rw-r--r-- 1 stc  stc   62245837 мар 20  2016 VID_20160320_120347.3gp

Т.е. фотки то все целиком на первом устройстве остались, а видосы (все кроме последнего) размазались по двум устройствам и с-но при монтировании любого одного устройства этим файлам - кирдык.
Пользователь добавил сообщение 24 Января 2017, 12:31:26:Вот поставил эксперимент с RAID0 - вообще ничего не понимаю :
Сделал на двух образах btrfs (data - RAID0, metadata - RAID1, system - RAID1)
смонтировал.
Записал на нее файлы от одного до 1024 байт длиной (по пять штук каждого).
Отмонтировал, убил loop со вторым образом.
Cмонтировал с -o degraded,ro
  все файлы доступны   

Пошел с другой стороны - отцепил первый образ, прицепил второй, смонтровал (degraded,ro) - опять все доступно
Ничего не понимаю.... а как же RAID0 


Пользователь добавил сообщение 24 Января 2017, 13:26:00:Попробовал файлы побольше и файлов побольше:
15034 файла, общим объёмом 1,9 GB (файлы от 100 до 250 600 байт размером, с шагом в 100 байт в размере).
Получилось такое:

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

$ sudo btrfs fi us .
Overall:
    Device size:    2.00GiB
    Device allocated:    2.00GiB
    Device unallocated:    2.00MiB
    Device missing:      0.00B
    Used:    1.80GiB
    Free (estimated): 104.00KiB (min: 104.00KiB)
    Data ratio:       1.00
    Metadata ratio:       2.00
    Global reserve:   16.00MiB (used: 0.00B)

Data,RAID0: Size:1.78GiB, Used:1.78GiB
   /dev/loop0 912.62MiB
   /dev/loop1 912.62MiB

Metadata,RAID1: Size:102.38MiB, Used:11.30MiB
   /dev/loop0 102.38MiB
   /dev/loop1 102.38MiB

System,RAID1: Size:8.00MiB, Used:16.00KiB
   /dev/loop0    8.00MiB
   /dev/loop1    8.00MiB

Unallocated:
   /dev/loop0    1.00MiB
   /dev/loop1    1.00MiBДемонтирую, убираю второй образ монтирую инвалида в РО:

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

Вот такой расклад с btrfs-ным RAID0

Как я понимаю маленькие файлы он зранит прямо в метаданных и т.к. они в RAID1 - то поэтому и доступны.
Файлы больше 4К хранятся целиком то на одном, то на другом дисках. Хотя скорее всего совсем большие файлы будут отдельными частями ложиться на разные диски

[Pilot6]

Ничего не понимаю....  а как же RAID0 

Файлы маленькие в inode хранятся, то есть в метаданных. Вот и доступны )))
Пользователь добавил сообщение 24 Января 2017, 13:27:55:Одновременно написали 
Пользователь добавил сообщение 24 Января 2017, 13:29:17:

Файлы больше 4К хранятся целиком то на одном, то на другом дисках.

Только при RAID0 по идее должно быть чередование, и файлы должны храниться на обоих дисках частями. Поэтому должны все погибать. Если это не так, тогда не понятно в чем тогда смысл RAID0 и чем он отличается от single.

Дошло. В btrfs этот рейд без чередования. Смотри на размер. Так что все правильно, что по умолчанию RAID0 создается.
Это просто вариант single для нескольких дисков.

[Sly_tom_cat]

Pilot6, ну если у них в "RAID0" нет чередования, то про какое чередование они пишут в моделя RAID5 и RAID6 ... да и в RAID10 - тоже?

[Pilot6]

Sly_tom_cat,
По идее должно быть. Это надо опять же в исходниках покопаться.

[Дмитрий Бо]

Фигня ваш Шаляпин.
У меня, я писал, диски примаплены с хранилищ, на компе multipath собирает их в устройства dm-N.

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

# ls -alh /dev/dm*
brw-rw---- 1 root disk 252, 0 фев  3 15:07 /dev/dm-0
brw-rw---- 1 root disk 252, 1 фев  3 14:56 /dev/dm-1
brw-rw---- 1 root disk 252, 2 фев  3 14:56 /dev/dm-2
brw-rw---- 1 root disk 252, 3 фев  3 14:56 /dev/dm-3
brw-rw---- 1 root disk 252, 4 фев  3 14:56 /dev/dm-4
brw-rw---- 1 root disk 252, 5 фев  3 14:56 /dev/dm-5
brw-rw---- 1 root disk 252, 6 фев  3 15:15 /dev/dm-6
brw-rw---- 1 root disk 252, 7 фев  3 15:08 /dev/dm-7
#
# ls -alh /dev/mapper/
итого 0
drwxr-xr-x  2 root root     220 фев  3 15:07 .
drwxr-xr-x 21 root root    5,0K фев  3 15:07 ..
lrwxrwxrwx  1 root root       7 фев  3 14:56 36006016013a12800e2b7e11938b8e611 -> ../dm-3
lrwxrwxrwx  1 root root       7 фев  3 14:56 36006016013a12800e2b7e11938b8e611-part1 -> ../dm-4
lrwxrwxrwx  1 root root       7 фев  3 15:07 3600a0b8000263d26000040e853386287 -> ../dm-0
lrwxrwxrwx  1 root root       7 фев  3 15:08 3600a0b8000263d26000040e853386287p1 -> ../dm-7
lrwxrwxrwx  1 root root       7 фев  3 14:56 3600a0b800026b1e4000004d257b9b98e -> ../dm-2
lrwxrwxrwx  1 root root       7 фев  3 15:15 3600a0b800026b1e4000004d257b9b98e-part1 -> ../dm-6
lrwxrwxrwx  1 root root       7 фев  3 14:56 3600a0b8000487f2800005a2055554ec3 -> ../dm-1
lrwxrwxrwx  1 root root       7 фев  3 14:56 3600a0b8000487f2800005a2055554ec3-part1 -> ../dm-5
crw-------  1 root root 10, 236 фев  3 14:56 control
Запиливаю btrfs:

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

# mkfs.btrfs /dev/mapper/3600a0b8000263d26000040e853386287p1
...
# mount /dev/mapper/3600a0b8000263d26000040e853386287p1 /mnt/backup/part3
# btrfs fi us /mnt/backup/part3
Overall:
    Device size:                 930.51GiB
    Device allocated:              2.02GiB
    Device unallocated:          928.49GiB
    Device missing:                  0.00B
    Used:                        512.00KiB
    Free (estimated):            928.50GiB      (min: 464.25GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:               16.00MiB      (used: 0.00B)

Data,single: Size:8.00MiB, Used:256.00KiB
   /dev/mapper/3600a0b8000263d26000040e853386287p1         8.00MiB

Metadata,DUP: Size:1.00GiB, Used:112.00KiB
   /dev/mapper/3600a0b8000263d26000040e853386287p1         2.00GiB

System,DUP: Size:8.00MiB, Used:16.00KiB
   /dev/mapper/3600a0b8000263d26000040e853386287p1        16.00MiB

Unallocated:
   /dev/mapper/3600a0b8000263d26000040e853386287p1       928.49GiB
Всё замечательно. Добавляем ещё диск:

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

# btrfs device add /dev/mapper/3600a0b800026b1e4000004d257b9b98e-part1 /mnt/backup/part3
# btrfs fi us /mnt/backup/part3
Overall:
    Device size:                   2.90TiB
    Device allocated:              2.02GiB
    Device unallocated:            2.89TiB
    Device missing:                  0.00B
    Used:                        512.00KiB
    Free (estimated):              2.89TiB      (min: 1.45TiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:               16.00MiB      (used: 0.00B)

Data,single: Size:8.00MiB, Used:256.00KiB
   /dev/mapper/3600a0b8000263d26000040e853386287p1         8.00MiB

Metadata,DUP: Size:1.00GiB, Used:112.00KiB
   /dev/mapper/3600a0b8000263d26000040e853386287p1         2.00GiB

System,DUP: Size:8.00MiB, Used:16.00KiB
   /dev/mapper/3600a0b8000263d26000040e853386287p1        16.00MiB

Unallocated:
   /dev/dm-6       1.99TiB
   /dev/mapper/3600a0b8000263d26000040e853386287p1       928.49GiBОпаньки, /dev/mapper/3600a0b800026b1e4000004d257b9b98e-part1 добавился как /dev/dm-6. Теперь добавляем ещё один диск, нумерация dm-устройств съезжает, /dev/dm-6 это уже что-то другое, ФС не может найти свою вторую половину и накрывается медным тазом
Есть шанс заставить его использовать симлинки, а не идти по ним? При создании можно же! А при добавлении - такие грабли

[Sly_tom_cat]

Дмитрий Бо, Может лучше по UID-ам девайсы прописывать через /dev/disk/by-uuid/ ?
Правда я не знаю выдает туда uuid-ы multipath - никогда с ним не сталкивался просто - не знаю что за зверь.

[ALiEN]

проясните про дефрагментацию:

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

$ mount | grep btrfs
  /dev/sda1 on / type btrfs (rw,noatime,space_cache,subvolid=257,subvol=/@)
  /dev/sda1 on /home type btrfs (rw,noatime,space_cache,subvolid=258,subvol=/@home)
$ filefrag ubuntu.iso
  ubuntu.iso: 702 extents found
$ btrfs fi defrag -r -v .
  ./ubuntu.iso
$ filefrag ubuntu.iso
  ubuntu.iso: 702 extents foundтак и должно быть? (как было 702, так и осталось)

[Sly_tom_cat]

ALiEN175, дефрагментатор делает то что может.

Это не баг, а фича ЛЮБОГО дефрагментатора (для любой ФС).

[Дмитрий Бо]

Sly_tom_cat, там всё сложнее. Ковырнул исходники, btrfs знает про симлинки и dm-устройства. Если указать dmN, то btrfs должен сам найти ему соответствующее устройство в /dev/mapper. Это запилили ещё в версии 3.18 или около того. И вот то ли он этого не делает, то ли делает, но отображает всё равно dm.
Ситуацию с разрушением тома стабильно повторить не получается. Может, просто совпадение и дело не в именовании кусков. А может и в нём, но только с -mconvert=raid1, но проверить не успел - ушёл в отпуск.