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

[ALiEN]

journalctl | grep -i btrfs
(инфы может быть очень много, смотрите по дате +/- 1 день)

dmesg | grep -i btrfs
(на всякий случай)

[tahr]

Аналогично с kern.log

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

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

Nov 21 03:51:07 xenial kernel: [27849.320124] ieee80211 phy0: wlan0: No probe response from AP 62:d9:a0:62:fc:4f after 500ms, disconnecting.
Nov 21 03:51:07 xenial NetworkManager[1226]: <warn>  [1511225467.7346] sup-iface[0x21b7d90,wlan0]: connection disconnected (reason -4)
Nov 21 03:51:07 xenial kernel: [27849.401726] cfg80211: World regulatory domain updated:
Nov 21 03:51:07 xenial kernel: [27849.401731] cfg80211:  DFS Master region: unset
Nov 21 03:51:07 xenial kernel: [27849.401733] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Nov 21 03:51:07 xenial kernel: [27849.401736] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Nov 21 03:51:07 xenial kernel: [27849.401738] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Nov 21 03:51:07 xenial kernel: [27849.401741] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
Nov 21 03:51:07 xenial kernel: [27849.401743] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
Nov 21 03:51:07 xenial kernel: [27849.401746] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
Nov 21 03:51:07 xenial kernel: [27849.401749] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
Nov 21 03:51:07 xenial kernel: [27849.401751] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
Nov 21 03:51:07 xenial kernel: [27849.401754] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
Nov 21 03:51:07 xenial NetworkManager[1226]: <info>  [1511225467.7558] device (wlan0): supplicant interface state: completed -> disconnected
Nov 21 03:51:07 xenial NetworkManager[1226]: <info>  [1511225467.8395] device (wlan0): supplicant interface state: disconnected -> scanning
Nov 21 03:51:23 xenial NetworkManager[1226]: <warn>  [1511225483.3544] device (wlan0): link timed out.
Nov 21 03:51:23 xenial NetworkManager[1226]: <info>  [1511225483.3545] device (wlan0): state change: activated -> failed (reason 'ssid-not-found') [100 120 53]
Nov 21 03:51:23 xenial NetworkManager[1226]: <info>  [1511225483.3550] manager: NetworkManager state is now CONNECTED_LOCAL
Nov 21 03:51:23 xenial NetworkManager[1226]: <info>  [1511225483.3553] manager: NetworkManager state is now DISCONNECTED
Nov 21 03:51:23 xenial NetworkManager[1226]: <warn>  [1511225483.3590] device (wlan0): Activation: failed for connection 'Lenovo P70-A'
Nov 21 03:51:23 xenial kernel: [27865.015641] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Nov 21 03:51:23 xenial NetworkManager[1226]: <info>  [1511225483.3651] device (wlan0): state change: failed -> disconnected (reason 'none') [120 30 0]
Nov 21 03:51:23 xenial NetworkManager[1226]: <info>  [1511225483.4002] dhcp4 (wlan0): canceled DHCP transaction, DHCP client pid 7128
Nov 21 03:51:23 xenial NetworkManager[1226]: <info>  [1511225483.4002] dhcp4 (wlan0): state changed bound -> done
Nov 21 03:51:23 xenial NetworkManager[1226]: <info>  [1511225483.4012] dns-mgr: Writing DNS information to /sbin/resolvconf
Nov 21 03:51:24 xenial NetworkManager[1226]: <info>  [1511225484.4835] device (wlan0): supplicant interface state: scanning -> inactive
Nov 21 03:51:40 xenial NetworkManager[1226]: <info>  [1511225500.9009] audit: op="radio-control" arg="wireless-enabled:1" pid=9228 uid=0 result="success"
Nov 21 03:51:41 xenial NetworkManager[1226]: <info>  [1511225501.1072] ModemManager disappeared from bus
Nov 21 17:24:50 xenial kernel: [    0.000000] microcode: CPU0 microcode updated early to revision 0xa0b, date = 2010-09-28
Nov 21 17:24:50 xenial kernel: [    0.000000] Initializing cgroup subsys cpuset
Nov 21 17:24:50 xenial kernel: [    0.000000] Initializing cgroup subsys cpu
Nov 21 17:24:50 xenial kernel: [    0.000000] Initializing cgroup subsys cpuacct
Nov 21 17:24:50 xenial kernel: [    0.000000] Linux version 4.4.0-87-generic (buildd@lcy01-31) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 (Ubuntu 4.4.0-87.110-generic 4.4.73)
Nov 21 17:24:50 xenial kernel: [    0.000000] Command line: BOOT_IMAGE=/@/boot/vmlinuz-4.4.0-87-generic root=/dev/sda9 ro rootflags=subvol=@
Nov 21 17:24:50 xenial kernel: [    0.000000] KERNEL supported cpus:
Nov 21 17:24:50 xenial kernel: [    0.000000]   Intel GenuineIntel
Nov 21 17:24:50 xenial kernel: [    0.000000]   AMD AuthenticAMD
Nov 21 17:24:50 xenial kernel: [    0.000000]   Centaur CentaurHauls
Nov 21 17:24:50 xenial kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
Nov 21 17:24:50 xenial kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
Nov 21 17:24:50 xenial kernel: [    0.000000] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format.
Nov 21 17:24:50 xenial kernel: [    0.000000] x86/fpu: Using 'lazy' FPU context switches.
Nov 21 17:24:50 xenial kernel: [    0.000000] e820: BIOS-provided physical RAM map:
Nov 21 17:24:50 xenial kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f3ff] usable

Да и что может писаться в логи, если ОС не загрузилась? Правильно, ничего.

Вот и интересно что там произошло, из-за чего ФС на ровном месте поломалась?
Пользователь добавил сообщение 21 Ноября 2017, 21:30:12:

(инфы может быть очень много, смотрите по дате +/- 1 день)

Это да. Но интересуют записи между Nov 21 03:51:41 и Nov 21 17:24:50, именно в этот промежуток времени был произведен ремонт ФС из сторонней системы. А записей таких, по идее, быть не должно, поскольку ОС была не загружена, выключена.
Разве что ФС сама в себе где-то в недрах еще информацию пишет.


Пользователь добавил сообщение 21 Ноября 2017, 21:32:46:

инфы может быть очень много

Оказалось мало:

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

mart@xenial:~$ journalctl | grep -i btrfs
ноя 21 17:24:40 xenial kernel: Btrfs loaded
ноя 21 17:24:40 xenial kernel: BTRFS: device label xerus devid 1 transid 220509 /dev/sda9
ноя 21 17:24:40 xenial kernel: BTRFS: device label slack devid 1 transid 128 /dev/sda8
ноя 21 17:24:40 xenial kernel: BTRFS: device label gent devid 1 transid 24 /dev/sda7
ноя 21 17:24:40 xenial kernel: BTRFS info (device sda9): disk space caching is enabled
ноя 21 17:24:40 xenial kernel: BTRFS: has skinny extents
ноя 21 17:24:42 xenial kernel: BTRFS info (device sda9): disk space caching is enabled
ноя 21 17:24:49 xenial kernel: BTRFS error (device sda9): could not find root 8
ноя 21 17:24:49 xenial kernel: BTRFS error (device sda9): could not find root 8
mart@xenial:~$ dmesg | grep -i btrfs
[    5.626130] Btrfs loaded
[    6.713754] BTRFS: device label xerus devid 1 transid 220509 /dev/sda9
[    6.714163] BTRFS: device label slack devid 1 transid 128 /dev/sda8
[    6.714499] BTRFS: device label gent devid 1 transid 24 /dev/sda7
[    6.843157] BTRFS info (device sda9): disk space caching is enabled
[    6.843235] BTRFS: has skinny extents
[   13.243406] BTRFS info (device sda9): disk space caching is enabled
[   20.063447] BTRFS error (device sda9): could not find root 8
[   20.063532] BTRFS error (device sda9): could not find root 8

ноя 21 17:24:49 xenial kernel: BTRFS error (device sda9): could not find root 8

Это как раз раздел, на котором стоит 16.04, в которой я сейчас нахожусь и проблем в работе не наблюдаю.

[Sly_tom_cat]

BTRFS error (device sda9): could not find root 8

Это фигня какая-то связанная с квотами (см. баг). Если разрешить квоты то это сообщение пропадает. Но на работу системы это сообщение не влияет.

[tahr]

Но на работу системы это сообщение не влияет.

Так и есть:

проблем в работе не наблюдаю.

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

[Sly_tom_cat]

Ну так вам уже написали - надо было при ремонте ФС смотреть что пишет "ремонтник". Сейчас, если в логах по даптам ничего найти не можете - то у же никто вам не скажет что было: FS уже отремонтирована и там нет уже следов сбоя.

[tahr]

Возьму на заметку, спасибо!

при ремонте ФС смотреть что пишет "ремонтник"

[Nikisch]

Странный баг у меня возник. Есть рейд1 (может и raid0 не помню) btrfs на сервере под некритичные задачи.
Я заменил пару дисков (которые вообще не монтировал), возможно эти переткнул в другие разъёмы или рейд контроллеры (чисто как порты используются). В результате мой массив btrfs не монтируется никак.

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

mount /dev/sde /var/spool/avreg
mount: wrong fs type, bad option, bad superblock on /dev/sde,
       missing codepage or helper program, or other error
/dev/sdf - то же самое

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

btrfs filesystem show
warning, device 4 is missing
warning, device 3 is missing
bytenr mismatch, want=20971520, have=0
Couldn't read chunk root
Label: none  uuid: 2f7ed800-8b71-401a-927d-84cd4ab610bb
        Total devices 4 FS bytes used 725.62GiB
        devid    1 size 698.64GiB used 373.00GiB path /dev/sde
        devid    2 size 698.64GiB used 373.00GiB path /dev/sdf
        *** Some devices missing
Было всего 2 девайса, а он хочет еще 2 к имеющимся? Подозреваю, что сменились некие идентификаторы дисков и он теперь мои за свои не считает. UUID не изменился, UUID_SUB я не помню ествественно.
/dev/sde: UUID="2f7ed800-8b71-401a-927d-84cd4ab610bb" UUID_SUB="b1b66abc-eb1b-40e5-98bc-0659aa8bee60" TYPE="btrfs"
/dev/sdf: UUID="2f7ed800-8b71-401a-927d-84cd4ab610bb" UUID_SUB="99807e5a-1799-4b0d-9777-7d58c6707802" TYPE="btrfs"

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

dmesg | tail
[157575.780215] BTRFS info (device sde): disk space caching is enabled
[157575.780217] BTRFS info (device sde): has skinny extents
[157575.780869] BTRFS error (device sde): failed to read chunk root
[157575.839141] BTRFS error (device sde): open_ctree failed
Можно его как-то заставить собрать массив вот из этих вот дисков и не выпендирваться?
ПС: вы че издеваетесь со своими капчами и загадками под каждым сообщением?

[AnrDaemon]

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

lsblk -o NAME,TYPE,SIZE,UUID,MOUNTPOINTВывод под спойлер.

[Sly_tom_cat]

Странный баг у меня возник. Есть рейд1 (может и raid0 не помню) btrfs на сервере под некритичные задачи.
Я заменил пару дисков (которые вообще не монтировал), возможно эти переткнул в другие разъёмы или рейд контроллеры (чисто как порты используются).

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

Как раньше было - можете все обратно подключить?

[Nikisch]

lsblk -o NAME,TYPE,SIZE,UUID,MOUNTPOINT

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

lsblk -o NAME,TYPE,SIZE,UUID,MOUNTPOINT
NAME    TYPE    SIZE UUID                                 MOUNTPOINT
sdf     disk  698,7G 2f7ed800-8b71-401a-927d-84cd4ab610bb
sdd     disk  931,5G                                     
├─sdd9  part      8M                                     
└─sdd1  part  931,5G 16021632836760954505                 
sdb     disk  931,5G                                     
├─sdb9  part      8M                                     
└─sdb1  part  931,5G 16021632836760954505                 
sdi     disk  465,8G                                     
└─sdi2  part     30G 7702db7c-2cc3-d2a7-975a-96869dedf01c
  └─md0 raid1    30G 2f7ad25c-5b36-439d-928e-1f5e636f36da /
sr0     rom    1024M                                     
sdg     disk    3,7T                                     
└─sdg3  part    3,6T 0186d186-9bca-4000-a744-844ccb6b935c /media/NetGear
sde     disk  698,7G 2f7ed800-8b71-401a-927d-84cd4ab610bb
sdc     disk  931,5G                                     
├─sdc9  part      8M                                     
└─sdc1  part  931,5G 16021632836760954505                 
sda     disk  931,5G                                     
├─sda9  part      8M                                     
└─sda1  part  931,5G 16021632836760954505                 
sdh     disk  465,8G                                     
└─sdh2  part     30G 7702db7c-2cc3-d2a7-975a-96869dedf01c
  └─md0 raid1    30G 2f7ad25c-5b36-439d-928e-1f5e636f36da /

Но ничего нового там нет.
Забыл сказать, что ядро 4.13 бUbuntu сервер 16.4. С опцией degrated тоже не робит.

Для начала не помните какой массив

Не принципиально, помнить должна техника, а не я.

"кручу верчу всех обмануть хочу"

все должно работать при любом порядке дисков. Для этого и придуманы UUID. Если бтрfs не может найти свои разделы, то еще один повод не юзать его. Щас мы от старожилов узнаем, что и диски и железо менять нельзя, да и вообще к компу подходить вредно.

Как раньше было - можете все обратно подключить?

И не подумаю. Проблема в бтрфс.

[tahr]

И не подумаю. Проблема в бтрфс.

При таком желании разбираться в проблеме вполне можно считать, что проблема уже решена.
Вот решение: не использовать btrfs.

[Sly_tom_cat]

Это даже не желание разбирается такое, а полное нежелание решать проблему.

Btrfs нормально с uuid работает... при подключении к нормальным портам. Но у вас через какие-то раид контроллеры все подключено. Вот с портами и надо разбираться... Но вам оно не надо. Вам надо назначить виноватого и получить кнопку "сделайте мне все зашибись".

[EvangelionDeath]

И не подумаю. Проблема в бтрфс.

Ну тогда и не делайте и не используйте BTRFS

Подозреваю, что сменились некие идентификаторы дисков и он теперь мои за свои не считает. UUID не изменился, UUID_SUB я не помню ествественно.

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

/dev/sde: UUID="2f7ed800-8b71-401a-927d-84cd4ab610bb" UUID_SUB="b1b66abc-eb1b-40e5-98bc-0659aa8bee60" TYPE="btrfs"
/dev/sdf: UUID="2f7ed800-8b71-401a-927d-84cd4ab610bb" UUID_SUB="99807e5a-1799-4b0d-9777-7d58c6707802" TYPE="btrfs"


Серьезно? Не, вы хоть знаете что такое UUID? Вообще-то стандарт говорит, что два устройства не могут преднамерено непреднамерено получить одинаковый идентификатор. А уж тем более что бы он поменялся от "фонаря".

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

sudo mount -o degredad /dev/sde /mnt
sudo btrfs device delete missing /mnt
И вообще, было бы неплохо, если бы Вы показали таки /etc/fstab

[ALiEN]

Вообще-то стандарт говорит, что два устройства не могут преднамерено получить одинаковый идентификатор

Не, в случае btrfs на нескольких устройствах так и будут одинаковые UUID.

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

Добавил флешку:

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

sudo btrfs device add -f /dev/sdb /

lsblk -o NAME,UUID
NAME  UUID
sda   a548aed1-16a6-4a18-9b3d-d947a492e743
sdb   a548aed1-16a6-4a18-9b3d-d947a492e743


sudo btrfs filesystem show
Label: none  uuid: a548aed1-16a6-4a18-9b3d-d947a492e743
Total devices 2 FS bytes used 194.27GiB
devid    1 size 232.89GiB used 206.07GiB path /dev/sda
devid    2 size 3.75GiB used 0.00B path /dev/sdb

[EvangelionDeath]

Не, в случае btrfs на нескольких устройствах так и будут одинаковые UUID.

Извиняюсь. Я пропустил "не". Правильно читать:

два устройства не могут непреднамерено получить одинаковый идентификатор

То есть BTRFS специально проставляет "одинаковый" для рейда).
А потому реально хотаелось бы увидеть, что твоится в fstab у человека с этой проблемой

Сообщение поправил.