我有一台运行 btrfs raid 6 阵列的服务器,该阵列似乎已损坏。当尝试安装它时,我收到以下错误消息。我不知道它是如何或为什么坏的,可能是停电之类的(它发生在我度假期间)。
root@storage:/home/administrator# mount /dev/sdb /mnt/storage/
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
我尝试-o recovery,ro | -o degraded| -o clear_cache
所有给出相同的错误消息。
检查 dmesg 时,这是输出。
BTRFS info (device sde): enabling auto recovery
BTRFS info (device sde): disk space caching is enabled
BTRFS: bdev /dev/sde errs: wr 1759, rd 0, flush 1091, corrupt 0, gen 0
BTRFS (device sde): parent transid verify failed on 17548820480 wanted 19215 found 18180
BTRFS (device sde): parent transid verify failed on 17548820480 wanted 19215 found 18180
BTRFS (device sde): parent transid verify failed on 17548820480 wanted 19215 found 18180
BTRFS (device sde): parent transid verify failed on 17548820480 wanted 19215 found 18180
BTRFS (device sde): parent transid verify failed on 17548820480 wanted 19215 found 18180
BTRFS (device sde): parent transid verify failed on 17548820480 wanted 19215 found 18180
BTRFS: error (device sde) in open_ctree:2897: errno=-5 IO failure (Failed to recover log tree)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 11885 at /build/linux-SKpZC9/linux-3.19.0/fs/btrfs/extent-tree.c:137 btrfs_put_block_group+0x71/0x80 [btrfs]()
Modules linked in: iosf_mbi coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ppdev aesni_intel aes_x86_64 lrw vmw_balloon gf128mul glue_helper ablk_helper cryptd serio_raw vmwgfx ttm drm_kms_helper drm i2c_piix4 vmw_vmci shpchp 8250_fintek parport_pc parport mac_hid nfsd auth_rpcgss nfs_acl lockd grace sunrpc autofs4 btrfs xor raid6_pq psmouse vmxnet3 mptspi mpt2sas raid_class scsi_transport_sas mptscsih mptbase scsi_transport_spi pata_acpi
CPU: 0 PID: 11885 Comm: mount Tainted: G W 3.19.0-26-generic #28-Ubuntu
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014
ffffffffc029dc10 ffff88002f0cfb88 ffffffff817c45cf 0000000000000007
0000000000000000 ffff88002f0cfbc8 ffffffff81076a6a ffff88003a0fb000
ffff88003bc34400 ffff88003bc34400 ffff88003a0fb080 ffff88003a0fb000
Call Trace:
[<ffffffff817c45cf>] dump_stack+0x45/0x57
[<ffffffff81076a6a>] warn_slowpath_common+0x8a/0xc0
[<ffffffff81076b5a>] warn_slowpath_null+0x1a/0x20
[<ffffffffc01fd2d1>] btrfs_put_block_group+0x71/0x80 [btrfs]
[<ffffffffc02078e8>] btrfs_free_block_groups+0x108/0x460 [btrfs]
[<ffffffffc0216bb6>] open_ctree+0x1896/0x2090 [btrfs]
[<ffffffffc01ecb10>] btrfs_mount+0x860/0x930 [btrfs]
[<ffffffff811f8e88>] mount_fs+0x38/0x1c0
[<ffffffff8119ce25>] ? __alloc_percpu+0x15/0x20
[<ffffffff8121556b>] vfs_kern_mount+0x6b/0x120
[<ffffffff812183be>] do_mount+0x21e/0xcb0
[<ffffffff8121916b>] SyS_mount+0x8b/0xd0
[<ffffffff817cb70d>] system_call_fastpath+0x16/0x1b
---[ end trace 7bbd52ae33403cc9 ]---
BTRFS: open_ctree failed
我btrfs rescue super-recover -y -v /dev/sdb
也跑了btrfs rescue chunk-recover -y -v /dev/sdb
。当我运行超级恢复时,它说一切都很好。运行块恢复需要很长时间,但没有修复我看到的任何内容。
运行结果root@storage:/home/administrator# btrfs rescue chunk-recover -y -v /dev/sdb
可以看到这里在过去的垃圾箱有点长