recovery problem raid5
Hello all,
I give up for this problem at restore my data
# uname -a Linux jarvis.home 4.5.0-1.el7.elrepo.x86_64
# btrfs --version btrfs-progs v3.19.1
# btrfs fi show
warning, device 4 is missing
bytenr mismatch, want=21020672, have=21217280
Couldn't read chunk root
Label: none uuid: 27ef2638-b50a-4243-80ed-40c3733ec11d
Total devices 4 FS bytes used 2.50TiB
devid 1 size 931.51GiB used 899.71GiB path /dev/sdd
devid 2 size 931.51GiB used 899.69GiB path /dev/sdb
devid 3 size 931.51GiB used 899.69GiB path /dev/sdc
*** Some devices missing# mount -o recovery /dev/sda /srv/
mount: wrong fs type, bad option, bad superblock on /dev/sda,
missing codepage or helper program, or other errorIn some cases useful info is found in syslog - try dmesg | tail or so.
dmesg after :
[ 4886.521315] BTRFS info (device sdc): enabling auto recovery [ 4886.521320] BTRFS info (device sdc): disk space caching is enabled [ 4886.522853] BTRFS: failed to read chunk tree on sdc [ 4886.528789] BTRFS: open_ctree failed
#btrfs check --repair /dev/sda
enabling repair mode
warning, device 4 is missing
bytenr mismatch, want=21020672, have=21217280
Couldn't read chunk root
Couldn't open file system
# btrfs rescue chunk-recover -v /dev/sda
All Devices:
Device: id = 3, name = /dev/sdc
Device: id = 2, name = /dev/sdb
Device: id = 1, name = /dev/sda[ 5164.468272] btrfs[3653]: segfault at 7f454014172e ip 0000000000423479 sp 00007f4482cec880 error 4 in btrfs[400000+83000] [ 5168.928317] btrfs[3657]: segfault at 7fd18c14172e ip 0000000000423479 sp 00007fd0d5858880 error 4 in btrfs[400000+83000] [ 5173.812457] btrfs[3662]: segfault at 7fd76c14172e ip 0000000000423479 sp 00007fd6b0e59880 error 4 in btrfs[400000+83000]
# btrfs rescue super-recover -v /dev/sda
All Devices:
Device: id = 3, name = /dev/sdc
Device: id = 2, name = /dev/sdb
Device: id = 1, name = /dev/sdaBefore Recovering:
[All good supers]:
device name = /dev/sdc
superblock bytenr = 65536
device name = /dev/sdc
superblock bytenr = 67108864
device name = /dev/sdc
superblock bytenr = 274877906944
device name = /dev/sdb
superblock bytenr = 65536
device name = /dev/sdb
superblock bytenr = 67108864
device name = /dev/sdb
superblock bytenr = 274877906944
device name = /dev/sda
superblock bytenr = 65536
device name = /dev/sda
superblock bytenr = 67108864
device name = /dev/sda
superblock bytenr = 274877906944
[All bad supers]:
All supers are valid, no need to recover
# btrfs-show-super /dev/sda
superblock: bytenr=65536, device=/dev/sda
---------------------------------------------------------
csum 0x61b509bb [match]
bytenr 65536
flags 0x1
magic _BHRfS_M [match]
fsid 27ef2638-b50a-4243-80ed-40c3733ec11d
label
generation 69462
root 1648640000
sys_array_size 290
chunk_root_generation 48545
root_level 1
chunk_root 21020672
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 4000819544064
bytes_used 2743528714240
sectorsize 4096
nodesize 16384
leafsize 16384
stripesize 4096
root_dir 6
num_devices 4
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0xe1
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF |
RAID56 )
csum_type 0
csum_size 4
cache_generation 69462
uuid_tree_generation 69462
dev_item.uuid 70f4650c-e01d-4613-bd7a-a6834c1c44bb
dev_item.fsid 27ef2638-b50a-4243-80ed-40c3733ec11d [match]
dev_item.type 0
dev_item.total_bytes 1000204886016
dev_item.bytes_used 966057263104
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0thx for helps
[ 88.423604] BTRFS warning (device sdc): devid 4 uuid c24f39f8-c73c-4a17-bbef-cb8988adcbf7 is missing [ 88.455607] BTRFS info (device sdc): bdev (null) errs: wr 921, rd 164889, flush 0, corrupt 0, gen 0 [ 88.800609] BTRFS error (device sdc): bad tree block start 0 1619525632 [ 88.800648] BTRFS: Failed to read block groups: -5 [ 88.809756] BTRFS: open_ctree failed [ 143.792547] BTRFS info (device sdc): allowing degraded mounts [ 143.792552] BTRFS info (device sdc): disk space caching is enabled [ 143.802719] BTRFS info (device sdc): bdev (null) errs: wr 921, rd 164889, flush 0, corrupt 0, gen 0 [ 143.874370] BTRFS error (device sdc): bad tree block start 0 1619525632 [ 143.874410] BTRFS: Failed to read block groups: -5 [ 143.883571] BTRFS: open_ctree failed [ 402.564374] BTRFS info (device sdc): enabling auto recovery [ 402.564379] BTRFS info (device sdc): disk space caching is enabled [ 402.565551] BTRFS: failed to read chunk tree on sdc [ 402.570197] BTRFS: open_ctree failed [ 604.273452] btrfs[2536]: segfault at 7f7fe014172e ip 0000000000423479 sp 00007f7f21358880 error 4 in btrfs[400000+83000] [ 1101.315762] BTRFS info (device sdc): enabling auto recovery [ 1101.315766] BTRFS info (device sdc): disk space caching is enabled [ 1101.316980] BTRFS: failed to read chunk tree on sdc [ 1101.323006] BTRFS: open_ctree failed [ 1124.008691] BTRFS info (device sdc): enabling auto recovery [ 1124.008695] BTRFS info (device sdc): disk space caching is enabled [ 1124.009859] BTRFS: failed to read chunk tree on sdc [ 1124.013344] BTRFS: open_ctree failed [ 1151.424614] btrfs[2666]: segfault at 7f8ff414172e ip 0000000000423479 sp 00007f8f3bcf3880 error 4 in btrfs[400000+83000] [ 1191.661205] btrfs[2677]: segfault at 7f060014172e ip 0000000000423479 sp 00007f0545789880 error 4 in btrfs[400000+83000] [ 2368.120700] BTRFS info (device sdc): enabling auto recovery [ 2368.120704] BTRFS info (device sdc): disk space caching is enabled [ 2368.121924] BTRFS: failed to read chunk tree on sdc [ 2368.126591] BTRFS: open_ctree failed [ 2370.738712] BTRFS info (device sdc): enabling auto recovery [ 2370.738717] BTRFS info (device sdc): disk space caching is enabled [ 2370.740003] BTRFS: failed to read chunk tree on sdc [ 2370.744624] BTRFS: open_ctree failed [ 2373.002807] BTRFS info (device sdc): enabling auto recovery [ 2373.002811] BTRFS info (device sdc): disk space caching is enabled [ 2373.004001] BTRFS: failed to read chunk tree on sdc [ 2373.007651] BTRFS: open_ctree failed [ 2513.800271] BTRFS info (device sdc): enabling auto recovery [ 2513.800276] BTRFS info (device sdc): disk space caching is enabled [ 2513.802181] BTRFS: failed to read chunk tree on sdc [ 2513.808614] BTRFS: open_ctree failed [ 2972.448037] btrfs[3152]: segfault at 7f454c14172e ip 0000000000423479 sp 00007f4494305880 error 4 in btrfs[400000+83000] [ 3123.647370] BTRFS info (device sdb): enabling auto recovery [ 3123.647375] BTRFS info (device sdb): disk space caching is enabled [ 3123.648233] BTRFS: failed to read chunk root on sdb [ 3123.655235] BTRFS: open_ctree failed [ 3131.574580] BTRFS info (device sdb): enabling auto recovery [ 3131.574585] BTRFS info (device sdb): disk space caching is enabled [ 3131.575360] BTRFS: failed to read chunk root on sdb [ 3131.582234] BTRFS: open_ctree failed
The main thing you haven't tried here is mount -o degraded, which
is the thing to do if you have a missing device in your array.
Also, that kernel's not really all that good for a parity RAID
array -- it's the very first one that had the scrub and replace implementation, so it's rather less stable with parity RAID than the later 4.x kernels. That's probably not the issue here, though.
Hugo.
Quoted 147 lines · Marcin Solecki
Hello all,
I give up for this problem at restore my data# uname -a Linux jarvis.home 4.5.0-1.el7.elrepo.x86_64# btrfs --version btrfs-progs v3.19.1# btrfs fi show warning, device 4 is missing bytenr mismatch, want=21020672, have=21217280 Couldn't read chunk root Label: none uuid: 27ef2638-b50a-4243-80ed-40c3733ec11d Total devices 4 FS bytes used 2.50TiB devid 1 size 931.51GiB used 899.71GiB path /dev/sdd devid 2 size 931.51GiB used 899.69GiB path /dev/sdb devid 3 size 931.51GiB used 899.69GiB path /dev/sdc *** Some devices missing# mount -o recovery /dev/sda /srv/ mount: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other errorIn some cases useful info is found in syslog - try dmesg | tail or so.
dmesg after :
[ 4886.521315] BTRFS info (device sdc): enabling auto recovery [ 4886.521320] BTRFS info (device sdc): disk space caching is enabled [ 4886.522853] BTRFS: failed to read chunk tree on sdc [ 4886.528789] BTRFS: open_ctree failed#btrfs check --repair
/dev/sda
enabling repair mode
warning, device 4 is missing
bytenr mismatch, want=21020672, have=21217280
Couldn't read chunk root
Couldn't open file system# btrfs rescue chunk-recover -v /dev/sda All Devices: Device: id = 3, name = /dev/sdc Device: id = 2, name = /dev/sdb Device: id = 1, name = /dev/sda[ 5164.468272] btrfs[3653]: segfault at 7f454014172e ip 0000000000423479 sp 00007f4482cec880 error 4 in btrfs[400000+83000] [ 5168.928317] btrfs[3657]: segfault at 7fd18c14172e ip 0000000000423479 sp 00007fd0d5858880 error 4 in btrfs[400000+83000] [ 5173.812457] btrfs[3662]: segfault at 7fd76c14172e ip0000000000423479 sp
00007fd6b0e59880error 4 in btrfs[400000+83000]# btrfs rescue super-recover -v /dev/sda All Devices: Device: id = 3, name = /dev/sdc Device: id = 2, name = /dev/sdb Device: id = 1, name = /dev/sdaBefore Recovering:
[All good supers]:
device name =/dev/sdc
superblock bytenr = 65536device name =
/dev/sdc
superblock bytenr = 67108864device name =
/dev/sdc
superblock bytenr = 274877906944device name =
/dev/sdb
superblock bytenr = 65536device name =
/dev/sdb
superblock bytenr = 67108864device name =
/dev/sdb
superblock bytenr = 274877906944device name =
/dev/sda
superblock bytenr = 65536device name =
/dev/sda
superblock bytenr = 67108864device name =
/dev/sda
superblock bytenr = 274877906944[All bad supers]:
All supers are valid, no need to recover
# btrfs-show-super /dev/sda superblock: bytenr=65536, device=/dev/sda --------------------------------------------------------- csum 0x61b509bb [match] bytenr 65536 flags 0x1 magic _BHRfS_M [match] fsid 27ef2638-b50a-4243-80ed-40c3733ec11d label generation 69462 root 1648640000 sys_array_size 290 chunk_root_generation 48545 root_level 1 chunk_root 21020672 chunk_root_level 1 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 4000819544064 bytes_used 2743528714240 sectorsize 4096 nodesize 16384 leafsize 16384 stripesize 4096 root_dir 6 num_devices 4 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0xe1 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | RAID56 ) csum_type 0 csum_size 4 cache_generation 69462 uuid_tree_generation 69462 dev_item.uuid 70f4650c-e01d-4613-bd7a-a6834c1c44bb dev_item.fsid 27ef2638-b50a-4243-80ed-40c3733ec11d [match] dev_item.type 0 dev_item.total_bytes 1000204886016 dev_item.bytes_used 966057263104 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size 4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0thx for helps
Signature · 4 lines
Hugo Mills | You can't expect a boy to be vicious until he's gone hugo@... carfax.org.uk | to a good school. http://carfax.org.uk/ | PGP: E2AB1DE4 | Saki
I try mount with -o degraded but this same effect what recovery:
[ 7133.926778] BTRFS info (device sdc): allowing degraded mounts [ 7133.926783] BTRFS info (device sdc): disk space caching is enabled [ 7133.932140] BTRFS info (device sdc): bdev (null) errs: wr 921, rd 164889, flush 0, corrupt 0, gen 0 [ 7133.993146] BTRFS error (device sdc): bad tree block start 0 1619525632 [ 7133.993185] BTRFS: Failed to read block groups: -5 [ 7134.002111] BTRFS: open_ctree failed
Do you suggest to return for stable kernel on centos? ( 3.10 )
W dniu 2016-03-18 o 19:02, Hugo Mills pisze:
Quoted 158 lines
The main thing you haven't tried here is mount -o degraded, which
is the thing to do if you have a missing device in your array.Also, that kernel's not really all that good for a parity RAID
array -- it's the very first one that had the scrub and replace implementation, so it's rather less stable with parity RAID than the later 4.x kernels. That's probably not the issue here, though.Hugo.
Quoted 147 lines · Marcin Solecki
Hello all,
I give up for this problem at restore my data# uname -a Linux jarvis.home 4.5.0-1.el7.elrepo.x86_64# btrfs --version btrfs-progs v3.19.1# btrfs fi show warning, device 4 is missing bytenr mismatch, want=21020672, have=21217280 Couldn't read chunk root Label: none uuid: 27ef2638-b50a-4243-80ed-40c3733ec11d Total devices 4 FS bytes used 2.50TiB devid 1 size 931.51GiB used 899.71GiB path /dev/sdd devid 2 size 931.51GiB used 899.69GiB path /dev/sdb devid 3 size 931.51GiB used 899.69GiB path /dev/sdc *** Some devices missing# mount -o recovery /dev/sda /srv/ mount: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other errorIn some cases useful info is found in syslog - try dmesg | tail or so.
dmesg after :
[ 4886.521315] BTRFS info (device sdc): enabling auto recovery [ 4886.521320] BTRFS info (device sdc): disk space caching is enabled [ 4886.522853] BTRFS: failed to read chunk tree on sdc [ 4886.528789] BTRFS: open_ctree failed#btrfs check --repair
/dev/sda
enabling repair mode
warning, device 4 is missing
bytenr mismatch, want=21020672, have=21217280
Couldn't read chunk root
Couldn't open file system# btrfs rescue chunk-recover -v /dev/sda All Devices: Device: id = 3, name = /dev/sdc Device: id = 2, name = /dev/sdb Device: id = 1, name = /dev/sda[ 5164.468272] btrfs[3653]: segfault at 7f454014172e ip 0000000000423479 sp 00007f4482cec880 error 4 in btrfs[400000+83000] [ 5168.928317] btrfs[3657]: segfault at 7fd18c14172e ip 0000000000423479 sp 00007fd0d5858880 error 4 in btrfs[400000+83000] [ 5173.812457] btrfs[3662]: segfault at 7fd76c14172e ip0000000000423479 sp
00007fd6b0e59880error 4 in btrfs[400000+83000]# btrfs rescue super-recover -v /dev/sda All Devices: Device: id = 3, name = /dev/sdc Device: id = 2, name = /dev/sdb Device: id = 1, name = /dev/sdaBefore Recovering:
[All good supers]:
device name =/dev/sdc
superblock bytenr = 65536device name =
/dev/sdc
superblock bytenr = 67108864device name =
/dev/sdc
superblock bytenr = 274877906944device name =
/dev/sdb
superblock bytenr = 65536device name =
/dev/sdb
superblock bytenr = 67108864device name =
/dev/sdb
superblock bytenr = 274877906944device name =
/dev/sda
superblock bytenr = 65536device name =
/dev/sda
superblock bytenr = 67108864device name =
/dev/sda
superblock bytenr = 274877906944[All bad supers]:
All supers are valid, no need to recover
# btrfs-show-super /dev/sda superblock: bytenr=65536, device=/dev/sda --------------------------------------------------------- csum 0x61b509bb [match] bytenr 65536 flags 0x1 magic _BHRfS_M [match] fsid 27ef2638-b50a-4243-80ed-40c3733ec11d label generation 69462 root 1648640000 sys_array_size 290 chunk_root_generation 48545 root_level 1 chunk_root 21020672 chunk_root_level 1 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 4000819544064 bytes_used 2743528714240 sectorsize 4096 nodesize 16384 leafsize 16384 stripesize 4096 root_dir 6 num_devices 4 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0xe1 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | RAID56 ) csum_type 0 csum_size 4 cache_generation 69462 uuid_tree_generation 69462 dev_item.uuid 70f4650c-e01d-4613-bd7a-a6834c1c44bb dev_item.fsid 27ef2638-b50a-4243-80ed-40c3733ec11d [match] dev_item.type 0 dev_item.total_bytes 1000204886016 dev_item.bytes_used 966057263104 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size 4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0thx for helps
Signature · 1 line
Pozdrawiam Marcin Solecki
Quoted 7 lines · Hugo Mills
The main thing you haven't tried here is mount -o degraded, which
is the thing to do if you have a missing device in your array.Also, that kernel's not really all that good for a parity RAID
array -- it's the very first one that had the scrub and replace implementation, so it's rather less stable with parity RAID than the later 4.x kernels. That's probably not the issue here, though.
It's a 4.5.0 kernel with 3.19 progs. I'd update the progs even though that's unlikely the problem.
Signature · 1 line
Chris Murphy
Quoted 4 lines · Chris Murphy
Quoted 3 lines · Hugo Mills
The main thing you haven't tried here is mount -o degraded, which
is the thing to do if you have a missing device in your array.
Quoted 8 lines
Quoted 4 lines
Also, that kernel's not really all that good for a parity RAID
array -- it's the very first one that had the scrub and replace implementation, so it's rather less stable with parity RAID than the later 4.x kernels. That's probably not the issue here, though.It's a 4.5.0 kernel with 3.19 progs. I'd update the progs even though that's unlikely the problem.
Oh, my mistake. I misread the 3.19 as the kernel version.
Marcin: Stick with the 4.5 kernel.
Hugo.
Signature · 4 lines
Hugo Mills | Yes, this is an example of something that becomes hugo@... carfax.org.uk | less explosive as a one-to-one cocrystal with TNT. http://carfax.org.uk/ | (Hexanitrohexaazaisowurtzitane) PGP: E2AB1DE4 | Derek Lowe
Quoted 11 lines · Chris Murphy
Quoted 7 lines · Hugo Mills
The main thing you haven't tried here is mount -o degraded, which
is the thing to do if you have a missing device in your array.Also, that kernel's not really all that good for a parity RAID
array -- it's the very first one that had the scrub and replace implementation, so it's rather less stable with parity RAID than the later 4.x kernels. That's probably not the issue here, though.It's a 4.5.0 kernel with 3.19 progs. I'd update the progs even though
And actually I'm wrong because it's possible progs 4.4.1 might help fix things. But really the problem is that -o degraded isn't work for the volume with a single missing device and I can't tell you why. It might be a bug, but it might be that progs 3.19 --repair wasn't a good idea to do on a volume with one missing device.
I'm really skeptical of any sorts of repairs being allowed without a scary warning and requiring a force flag on volumes that are degraded. I know this is possible with ext4 and XFS, but that's only because they have no idea when the underlying raid is degraded.
Signature · 1 line
Chris Murphy
W dniu 2016-03-19 o 00:40, Chris Murphy pisze:
Quoted 17 lines · Chris Murphy
Quoted 10 lines · Hugo Mills
Quoted 7 lines
The main thing you haven't tried here is mount -o degraded, which
is the thing to do if you have a missing device in your array.Also, that kernel's not really all that good for a parity RAID
array -- it's the very first one that had the scrub and replace implementation, so it's rather less stable with parity RAID than the later 4.x kernels. That's probably not the issue here, though.It's a 4.5.0 kernel with 3.19 progs. I'd update the progs even though
And actually I'm wrong because it's possible progs 4.4.1 might help fix things. But really the problem is that -o degraded isn't work for the volume with a single missing device and I can't tell you why. It might be a bug, but it might be that progs 3.19 --repair wasn't a good idea to do on a volume with one missing device.
Quoted 6 lines
I'm really skeptical of any sorts of repairs being allowed without a scary warning and requiring a force flag on volumes that are degraded. I know this is possible with ext4 and XFS, but that's only because they have no idea when the underlying raid is degraded.
I try on fedora 23, kernel line 4.x and btrfs progs 4.x ( don't remember ), already I resigned to the loss of data but I want to try anything what you suggest
Signature · 1 line
Pozdrawiam Marcin Solecki
Hugo Mills posted on Fri, 18 Mar 2016 18:02:07 +0000 as excerpted:
Quoted 10 lines
Also, that kernel's not really all that good for a parity RAID array -- it's the very first one that had the scrub and replace implementation, so it's rather less stable with parity RAID than the later 4.x kernels. That's probably not the issue here, though.
Quoted 4 lines · Marcin Solecki
# uname -a Linux jarvis.home 4.5.0-1.el7.elrepo.x86_64# btrfs --version btrfs-progs v3.19.1
Umm... Hugo, look again. He's running current 4.5 kernel. It's the btrfs-progs version that's v3.19.1 and thus old.
Marcin. You're kernel is current and should be fine. It's the older kernels that have the most problems and 3.19 that was the first one with parity-raid scrub and replace, so Hugo obviously just read your post wrong.
Other than that, I'd normally trust Hugo's recommendations over any I might offer, and mount -o degraded is indeed precisely what's supposed to be used in a missing device situation, so I agree with him there.
You might consider upgrading userspace (btrfs-progs), as Hugo does have a point, if he did make it about the wrong thing, and while a 3.19 era userspace should work, given that full parity-raid support was very new at that point, a current 4.4.1 userspace may well have a few more bugfixes, tho I've not tracked the parity-raid support specifically enough to know for sure if it has any that apply to that. But once he figures out you were talking about 3.19.1 userspace, not 3.19.1 kernel, Hugo will probably know more which if any parity-raid specific changes have been made to btrfs-progs since 3.19, as well.
(Of course, the wiki has a short user-targeted description of what changed in each btrfs-progs release as well, and I could look it up there if wanted to, but so can you, and I'm using the older raid1, not parity- raid, so I don't have the direct personal interest in that info that you might, so...)
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman