Synology - O volume BTRFS travou e foi recuperado. Por que caiu?

Question

Visitei o WebGUI. Não houve nenhum erro no sistema, exceto o volume estar offline.

O status SMART de cada disco foi verificado e parecia OK
"Storage Manager" mostrou "Saudável"
"Pool de armazenamento" mostrou "Saudável"

Apenas "volume" mostrou falha.

Eu fiz SSH e verifiquei. mdadm --D /dev/md2que é onde estava meu array. Estava mostrandoState: Clean, Degraded

Verifiquei o dmesg e encontrei isto:

[5638907.327288] ------------[ cut here ]------------
[5638907.332247] WARNING: CPU: 3 PID: 10234 at fs/btrfs/extent-tree.c:4207 btrfs_write_dirty_block_groups+0x365/0x390 [btrfs]()
[5638907.343601] BTRFS: Transaction aborted (error -2)
[5638907.343603] Modules linked in: nfsd exportfs rpcsec_gss_krb5 cifs udf isofs loop tcm_loop(O) iscsi_target_mod(O) target_core_ep(O) target_core_multi_file(O) target_core_file(O) target_core_iblock(O) target_core_mod(O) syno_extent_pool(PO) rodsp_ep(O) hid_generic usbhid hid usblp usb_storage denverton_synobios(PO) overlay exfat(O) btrfs synoacl_vfs(PO) hfsplus md4 hmac bnx2x(O) mdio mlx5_core(O) mlx4_en(O) mlx4_core(O) mlx_compat(O) qede(O) qed(O) atlantic(O) tn40xx(O) i40e(O) ixgbe(O) be2net(O) igb(O) i2c_algo_bit e1000e(O) vxlan ip6_udp_tunnel udp_tunnel fuse vfat fat crc32c_intel aesni_intel glue_helper lrw gf128mul ablk_helper arc4 cryptd ecryptfs sha256_generic ecb aes_x86_64 authenc des_generic ansi_cprng cts md5 cbc cpufreq_powersave cpufreq_performance acpi_cpufreq processor cpufreq_stats
[5638907.425092]  dm_snapshot dm_bufio crc_itu_t crc_ccitt quota_v2 quota_tree psnap p8022 llc sit tunnel4 ip_tunnel ipv6 zram sg etxhci_hcd xhci_pci xhci_hcd uhci_hcd ehci_pci ehci_hcd usbcore usb_common [last unloaded: denverton_synobios]
[5638907.448308] CPU: 3 PID: 10234 Comm: btrfs-transacti Tainted: P           O    4.4.59+ #25556
[5638907.457047] Hardware name: Synology Inc. RS2818RP+/Type2 - Board Product Name1, BIOS M.212 2019/11/01
[5638907.466571]  0000000000000000 ffff880068a0fc50 ffffffff812bf70d ffff880068a0fc98
[5638907.474851]  ffffffffa0939b8d ffff880068a0fc88 ffffffff8104b7cd ffff8801704f9e00
[5638907.483132]  ffff88003b616338 0000000000000001 00000000fffffffe ffff8801704f9f50
[5638907.491422] Call Trace:
[5638907.494179]  [<ffffffff812bf70d>] dump_stack+0x4d/0x70
[5638907.499623]  [<ffffffff8104b7cd>] warn_slowpath_common+0x7d/0xc0
[5638907.505932]  [<ffffffff8104b859>] warn_slowpath_fmt+0x49/0x50
[5638907.511996]  [<ffffffffa0892d45>] btrfs_write_dirty_block_groups+0x365/0x390 [btrfs]
[5638907.520056]  [<ffffffffa0932df8>] commit_cowonly_roots+0x230/0x2d1 [btrfs]
[5638907.527250]  [<ffffffffa08a90e8>] btrfs_commit_transaction+0x528/0xcb0 [btrfs]
[5638907.534793]  [<ffffffffa08a9905>] ? start_transaction+0x95/0x3d0 [btrfs]
[5638907.541810]  [<ffffffffa08a387c>] transaction_kthread+0x1ec/0x220 [btrfs]
[5638907.548915]  [<ffffffffa08a3690>] ? btrfs_cleanup_transaction+0x510/0x510 [btrfs]
[5638907.556701]  [<ffffffff810672a6>] kthread+0xc6/0xe0
[5638907.561883]  [<ffffffff810671e0>] ? kthread_create_on_node+0x180/0x180
[5638907.568717]  [<ffffffff81567abf>] ret_from_fork+0x3f/0x80
[5638907.574423]  [<ffffffff810671e0>] ? kthread_create_on_node+0x180/0x180
[5638907.581346] ---[ end trace 27185b26c2db1370 ]---
[5638907.586280] BTRFS: error (device md2) in btrfs_write_dirty_block_groups:4207: errno=-2 No such entry
[5638907.595721] BTRFS info (device md2): forced readonly
[5638907.600997] BTRFS warning (device md2): Skipping commit of aborted transaction.
[5638907.608618] BTRFS: error (device md2) in cleanup_transaction:2019: errno=-2 No such entry
[5638907.617108] BTRFS info (device md2): delayed_refs has NO entry

Portanto, os dados estavam lá e o array estava somente leitura. Minha pesquisa me levou a esta base de conhecimento do SuSe:https://www.suse.com/support/kb/doc/?id=000018769

Eu faço referência ao mesmo erro que recebi BTRFS: Transaction aborted (error -2).

O artigo afirma

O bom é que é um AVISO, não um erro fatal. AVISOs como este, por exemplo, relativos à cota, normalmente são coisas apenas em tempo de execução que são corrigidas pelo BTRFS após a emissão do AVISO. Não é um problema ruim.

O que foi um tanto reconfortante.

Eu corri um

syno_poweroff_task -d

Para desligar todos os serviços Synology que possam estar acessando o volume. Isso interrompe o WebUI etc., mas mantém o SSH ativado.

Eu então fiz um

umount /volume1

Para interromper a E/S do volume (embora já estivesse no modo RO de acordo com a saída dmesgacima. Fiz então um btrfsckno md2dispositivo. Saída abaixo

# btrfsck /dev/md2
Syno caseless feature on.
Checking filesystem on /dev/md2
UUID: 7a29febb-e9b5-4f77-afd7-4e1e10971340
checking extents
checking free space tree
checking fs roots
checking csums
checking root refs
found 30769182859264 bytes used err is 0
total csum bytes: 44052
total tree bytes: 50331648
total fs tree bytes: 24477696
total extent tree bytes: 23691264
btree space waste bytes: 1190925
file data blocks allocated: 30769149861888
referenced 30769131089920

E no dmesg:

[5644451.646580] BTRFS info (device md127): using free space tree
[5644451.652561] BTRFS info (device md127): has skinny extents
[5644459.827213] BTRFS info (device md127): checking UUID tree

Depois de concluído, simplesmente reiniciei o sistema e tudo voltou normalmente.

No momento, estou executando uma verificação de consistência de volume, que acredito ser uma "ressincronização" do mdadm que está em execução há quase 24 horas sem problemas.

Acho que o objetivo de fazer este post é descobrir se alguém com um pouco mais de conhecimento sobre btrfs já passou por isso e se tem alguma ideia do que causou isso?

Answer 1