* Help needed to recover from partition resize/move
@ 2020-04-25 10:24 Yegor Yegorov
2020-04-25 20:05 ` Chris Murphy
2020-04-26 11:04 ` Ferry Toth
0 siblings, 2 replies; 9+ messages in thread
From: Yegor Yegorov @ 2020-04-25 10:24 UTC (permalink / raw)
To: linux-btrfs
Hi, I have been stupid enough to try to move and extend my btrfs
partition using a GUI software of my distro. The operation ended with
an error. From the logs of the operation, I understood that the
movement of the partition succeeded, but some finishing operation is
failed. I don't have this log anymore, so I can't provide further
information on that.
Now I ended up with btrfs partition that can't be mounted. Here the
output of the various system and btrfs tools:
$> mount -t btrfs /dev/nvme0n1p3 /mnt/
mount: /mnt/: wrong fs type, bad option, bad superblock on
/dev/nvme0n1p3, missing codepage or helper program, or other error.
$>dmesg | tail
[11637.931751] BTRFS info (device nvme0n1p3): disk space caching is enabled
[11637.931754] BTRFS info (device nvme0n1p3): has skinny extents
[11637.936339] BTRFS error (device nvme0n1p3): bad tree block start,
want 1048576 have 6267530653245814412
[11637.936350] BTRFS error (device nvme0n1p3): failed to read chunk root
[11637.950289] BTRFS error (device nvme0n1p3): open_ctree failed
[11637.950893] audit: type=1106 audit(1587809374.388:663): pid=14229
uid=0 auid=1000 ses=2 msg='op=PAM:session_close
grantors=pam_limits,pam_unix,pam_permit acct="root"
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[11637.951039] audit: type=1104 audit(1587809374.388:664): pid=14229
uid=0 auid=1000 ses=2 msg='op=PAM:setcred
grantors=pam_unix,pam_permit,pam_env acct="root" exe="/usr/bin/sudo"
hostname=? addr=? terminal=/dev/pts/1 res=success'
[11674.981082] audit: type=1101 audit(1587809411.415:665): pid=14277
uid=1000 auid=1000 ses=2 msg='op=PAM:accounting
grantors=pam_unix,pam_permit,pam_time acct="go4a" exe="/usr/bin/sudo"
hostname=? addr=? terminal=/dev/pts/1 res=success'
[11674.981423] audit: type=1110 audit(1587809411.415:666): pid=14277
uid=0 auid=1000 ses=2 msg='op=PAM:setcred
grantors=pam_unix,pam_permit,pam_env acct="root" exe="/usr/bin/sudo"
hostname=? addr=? terminal=/dev/pts/1 res=success'
[11674.985959] audit: type=1105 audit(1587809411.422:667): pid=14277
uid=0 auid=1000 ses=2 msg='op=PAM:session_open
grantors=pam_limits,pam_unix,pam_permit acct="root"
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
$> btrfs check /dev/nvme0n1p3
Opening filesystem to check...
checksum verify failed on 1048576 found 00000067 wanted 0000006E
checksum verify failed on 1048576 found 00000067 wanted 0000006E
bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412
ERROR: cannot read chunk root
ERROR: cannot open file system
$> btrfs restore /dev/nvme0n1p3 /mnt/
checksum verify failed on 1048576 found 00000067 wanted 0000006E
checksum verify failed on 1048576 found 00000067 wanted 0000006E
bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412
ERROR: cannot read chunk root
Could not open root, trying backup super
checksum verify failed on 1048576 found 00000067 wanted 0000006E
checksum verify failed on 1048576 found 00000067 wanted 0000006E
bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412
ERROR: cannot read chunk root
Could not open root, trying backup super
ERROR: superblock bytenr 274877906944 is larger than device size 188743680000
Could not open root, trying backup super
$> btrfs rescue chunk-recover /dev/nvme0n1p3
Scanning: DONE in dev0
Check chunks successfully with no orphans
Chunk tree recovered successfully
$>btrfs rescue super-recover /dev/nvme0n1p3
All supers are valid, no need to recover
$>btrfs rescue zero-log /dev/nvme0n1p3
checksum verify failed on 1048576 found 00000067 wanted 0000006E
checksum verify failed on 1048576 found 00000067 wanted 0000006E
bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412
ERROR: cannot read chunk root
ERROR: could not open ctree
$>btrfs-find-root /dev/nvme0n1p3
WARNING: cannot read chunk root, continue anyway
Superblock thinks the generation is 49
Superblock thinks the level is 1
$>btrfs check --repair /dev/nvme0n1p3
Starting repair.
Opening filesystem to check...
checksum verify failed on 1048576 found 00000067 wanted 0000006E
checksum verify failed on 1048576 found 00000067 wanted 0000006E
bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412
ERROR: cannot read chunk root
ERROR: cannot open file system
$> btrfs check --repair --init-csum-tree --init-extent-tree /dev/nvme0n1p3
Starting repair.
Opening filesystem to check...
checksum verify failed on 1048576 found 00000067 wanted 0000006E
checksum verify failed on 1048576 found 00000067 wanted 0000006E
bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412
ERROR: cannot read chunk root
ERROR: cannot open file system
$> uname -a
Linux go4a-HP-Spectre 5.7.0-1-MANJARO #1 SMP PREEMPT Tue Apr 21
20:48:43 UTC 2020 x86_64 GNU/Linux
$> btrfs --version
btrfs-progs v5.6
$> btrfs fi show
Label: none uuid: 1e1d4296-9d34-4070-9d8b-18d5dfbad486
Total devices 1 FS bytes used 85.02GiB
devid 1 size 97.17GiB used 97.17GiB path /dev/nvme0n1p7
Label: 'data' uuid: 90e9d74c-3606-4028-9e72-c10e76f44a7c
Total devices 1 FS bytes used 169.51GiB
devid 1 size 175.78GiB used 172.02GiB path /dev/nvme0n1p3
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Help needed to recover from partition resize/move 2020-04-25 10:24 Help needed to recover from partition resize/move Yegor Yegorov @ 2020-04-25 20:05 ` Chris Murphy 2020-04-25 21:54 ` Yegor Yegorov 2020-04-26 11:04 ` Ferry Toth 1 sibling, 1 reply; 9+ messages in thread From: Chris Murphy @ 2020-04-25 20:05 UTC (permalink / raw) To: Yegor Yegorov; +Cc: Btrfs BTRFS On Sat, Apr 25, 2020 at 4:24 AM Yegor Yegorov <gochkin@gmail.com> wrote: > > Hi, I have been stupid enough to try to move and extend my btrfs > partition using a GUI software of my distro. The operation ended with > an error. From the logs of the operation, I understood that the > movement of the partition succeeded, but some finishing operation is > failed. I don't have this log anymore, so I can't provide further > information on that. > > Now I ended up with btrfs partition that can't be mounted. Here the > output of the various system and btrfs tools: > > $> mount -t btrfs /dev/nvme0n1p3 /mnt/ > mount: /mnt/: wrong fs type, bad option, bad superblock on > /dev/nvme0n1p3, missing codepage or helper program, or other error. > > $>dmesg | tail > [11637.931751] BTRFS info (device nvme0n1p3): disk space caching is enabled > [11637.931754] BTRFS info (device nvme0n1p3): has skinny extents > [11637.936339] BTRFS error (device nvme0n1p3): bad tree block start, > want 1048576 have 6267530653245814412 > [11637.936350] BTRFS error (device nvme0n1p3): failed to read chunk root > [11637.950289] BTRFS error (device nvme0n1p3): open_ctree failed > [11637.950893] audit: type=1106 audit(1587809374.388:663): pid=14229 > uid=0 auid=1000 ses=2 msg='op=PAM:session_close > grantors=pam_limits,pam_unix,pam_permit acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > [11637.951039] audit: type=1104 audit(1587809374.388:664): pid=14229 > uid=0 auid=1000 ses=2 msg='op=PAM:setcred > grantors=pam_unix,pam_permit,pam_env acct="root" exe="/usr/bin/sudo" > hostname=? addr=? terminal=/dev/pts/1 res=success' > [11674.981082] audit: type=1101 audit(1587809411.415:665): pid=14277 > uid=1000 auid=1000 ses=2 msg='op=PAM:accounting > grantors=pam_unix,pam_permit,pam_time acct="go4a" exe="/usr/bin/sudo" > hostname=? addr=? terminal=/dev/pts/1 res=success' > [11674.981423] audit: type=1110 audit(1587809411.415:666): pid=14277 > uid=0 auid=1000 ses=2 msg='op=PAM:setcred > grantors=pam_unix,pam_permit,pam_env acct="root" exe="/usr/bin/sudo" > hostname=? addr=? terminal=/dev/pts/1 res=success' > [11674.985959] audit: type=1105 audit(1587809411.422:667): pid=14277 > uid=0 auid=1000 ses=2 msg='op=PAM:session_open > grantors=pam_limits,pam_unix,pam_permit acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > > $> btrfs check /dev/nvme0n1p3 > Opening filesystem to check... > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > ERROR: cannot open file system > > $> btrfs restore /dev/nvme0n1p3 /mnt/ > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > Could not open root, trying backup super > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > Could not open root, trying backup super > ERROR: superblock bytenr 274877906944 is larger than device size 188743680000 This suggests the partition was changed (shrunk) before the file system shrink had succeeded; or that the partition was changed even after file system shrink failed. At this point it's required to make no changes to the file system, including repairs, until the partition size matches the file system size as reported by the superblock. > Could not open root, trying backup super > > $> btrfs rescue chunk-recover /dev/nvme0n1p3 > Scanning: DONE in dev0 > Check chunks successfully with no orphans > Chunk tree recovered successfully My suspicion is this might have made things worse. I don't see how chunk-recover can do the right thing, if the partition is wrong. And further I think that all of the Btrfs tools should do an early check that the partition size matches file system size, and if that fails, it should warn and stop. > > $>btrfs rescue super-recover /dev/nvme0n1p3 > All supers are valid, no need to recover True only in the narrow case that their checksum matches contents, sanity tests, and they match each other. But I still think even this tool should confirm/deny the very basic thing: partition size (or block device size) matches file system size. > > $>btrfs rescue zero-log /dev/nvme0n1p3 > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > ERROR: could not open ctree OK sorry but now you're just throwing spaghetti at a wall. It's desperation, which is a great way to cause further damage to a file system. Fortunately the log is not critical, it just means it's possible to lose the most recent data being written and fsync'd. > > $>btrfs-find-root /dev/nvme0n1p3 > WARNING: cannot read chunk root, continue anyway > Superblock thinks the generation is 49 > Superblock thinks the level is 1 > > $>btrfs check --repair /dev/nvme0n1p3 > Starting repair. > Opening filesystem to check... > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > ERROR: cannot open file system The want and have are way far apart, the file system is damaged. And I don't see how it can be fixed when the partition is smaller than the file system. Too much is missing and repair is impossible. Doing a repair in this case will make things worse. But again, I argue check even with --repair should quickly fail if there's a block device size and file system size mismatch, specifically the case where block device size is smaller than file system size, as in this case. > $> btrfs check --repair --init-csum-tree --init-extent-tree /dev/nvme0n1p3 > Starting repair. > Opening filesystem to check... > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > ERROR: cannot open file system The heavy hammer. Again, likely to make things worse, but luckily it can't find enough to proceed with the repair. You need to fix the partition/filesystem size mismatch first. fdisk -l /dev/sda btrfs insp dump-s /dev/sdaN where N is the partition for this file system -- Chris Murphy ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Help needed to recover from partition resize/move 2020-04-25 20:05 ` Chris Murphy @ 2020-04-25 21:54 ` Yegor Yegorov 2020-04-26 0:56 ` Chris Murphy 0 siblings, 1 reply; 9+ messages in thread From: Yegor Yegorov @ 2020-04-25 21:54 UTC (permalink / raw) To: Chris Murphy; +Cc: Btrfs BTRFS > You need to fix the partition/filesystem size mismatch first. > > fdisk -l /dev/sda > btrfs insp dump-s /dev/sdaN Hi Chris, thank you for taking the time to help me. The reason I performed all those actions is that those are the actions that are suggested in order to recover btrfs mount failures. I tried to perform them in order from the least to the most dangerous and only tried the next one after the previous one didn't help. In any case, I did have dumped the failed btrfs partition to .img file in case the things will go terribly wrong. I was hoping that I could just restore it if to much damage were introduced. But I did take an image only of the failed partition and not the entire drive, so now I'm afraid that maybe the data needed to restore the partition is gone or overwritten, because this data may be in the area outside the partition itself as you suggested. In any case, here are the outputs of the commands that you asked for: $> fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 476.96 GiB, 512110190592 bytes, 1000215216 sectors Disk model: SAMSUNG MZVLW512HMJP-000H1 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 63C1ED58-4B39-428F-90F1-9CA561B96111 Device Start End Sectors Size Type /dev/nvme0n1p1 2048 309247 307200 150M EFI System /dev/nvme0n1p2 775952384 796432383 20480000 9.8G Linux swap /dev/nvme0n1p3 309248 368949247 368640000 175.8G Linux filesystem /dev/nvme0n1p7 796432384 1000214527 203782144 97.2G Linux filesystem $> btrfs insp dump-s /dev/nvme0n1p3 superblock: bytenr=65536, device=/dev/nvme0n1p3 --------------------------------------------------------- csum_type 0 (crc32c) csum_size 4 csum 0x043ea018 [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid 90e9d74c-3606-4028-9e72-c10e76f44a7c metadata_uuid 90e9d74c-3606-4028-9e72-c10e76f44a7c label data generation 49 root 8612052992 sys_array_size 97 chunk_root_generation 46 root_level 1 chunk_root 1048576 chunk_root_level 1 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 188743680000 bytes_used 182011633664 sectorsize 4096 nodesize 16384 leafsize (deprecated) 16384 stripesize 4096 root_dir 6 num_devices 1 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0x161 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation 48 uuid_tree_generation 48 dev_item.uuid e2815a2c-6ec8-45c6-baae-7f429a5f0f78 dev_item.fsid 90e9d74c-3606-4028-9e72-c10e76f44a7c [match] dev_item.type 0 dev_item.total_bytes 188743680000 dev_item.bytes_used 184704565248 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 0 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Help needed to recover from partition resize/move 2020-04-25 21:54 ` Yegor Yegorov @ 2020-04-26 0:56 ` Chris Murphy 2020-04-26 5:58 ` Andrei Borzenkov 2020-04-26 6:23 ` Yegor Yegorov 0 siblings, 2 replies; 9+ messages in thread From: Chris Murphy @ 2020-04-26 0:56 UTC (permalink / raw) To: Yegor Yegorov; +Cc: Chris Murphy, Btrfs BTRFS On Sat, Apr 25, 2020 at 3:55 PM Yegor Yegorov <gochkin@gmail.com> wrote: > > /dev/nvme0n1p3 309248 368949247 368640000 175.8G Linux filesystem > total_bytes 188743680000 OK, actually I'm wrong. 188743680000/512=368640000 sectors, which matches the GPT partition. So I'm not sure what happened. > ERROR: superblock bytenr 274877906944 is larger than device size 188743680000 I don't see this value in the superblock. What do you get for btrfs insp dump-s -f /dev/nvme0n1p3 btfs insp dump-t -d /dev/nvme0n1p3 -- Chris Murphy ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Help needed to recover from partition resize/move 2020-04-26 0:56 ` Chris Murphy @ 2020-04-26 5:58 ` Andrei Borzenkov 2020-04-26 6:23 ` Yegor Yegorov 1 sibling, 0 replies; 9+ messages in thread From: Andrei Borzenkov @ 2020-04-26 5:58 UTC (permalink / raw) To: Chris Murphy, Yegor Yegorov; +Cc: Btrfs BTRFS 26.04.2020 03:56, Chris Murphy пишет: > On Sat, Apr 25, 2020 at 3:55 PM Yegor Yegorov <gochkin@gmail.com> wrote: >> >> /dev/nvme0n1p3 309248 368949247 368640000 175.8G Linux filesystem > >> total_bytes 188743680000 > > OK, actually I'm wrong. 188743680000/512=368640000 sectors, which > matches the GPT partition. So I'm not sure what happened. > The original error message (bad tree block start, want 1048576 have 6267530653245814412) means content of root node is wrong. 1048576 is where btrfs "starts". If you cannot read that, you do not have any way to reach other data. Likely something went wrong copying data. >> ERROR: superblock bytenr 274877906944 is larger than device size 188743680000 > > I don't see this value in the superblock. > This is the third superblock. "dump-super -a" may show it. > What do you get for > > btrfs insp dump-s -f /dev/nvme0n1p3 > btfs insp dump-t -d /dev/nvme0n1p3 > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Help needed to recover from partition resize/move 2020-04-26 0:56 ` Chris Murphy 2020-04-26 5:58 ` Andrei Borzenkov @ 2020-04-26 6:23 ` Yegor Yegorov 2020-04-26 7:36 ` Chris Murphy 1 sibling, 1 reply; 9+ messages in thread From: Yegor Yegorov @ 2020-04-26 6:23 UTC (permalink / raw) To: Chris Murphy; +Cc: Btrfs BTRFS, arvidjaar > What do you get for > > btrfs insp dump-s -f /dev/nvme0n1p3 > btfs insp dump-t -d /dev/nvme0n1p3 $> btrfs insp dump-s -f /dev/nvme0n1p3 superblock: bytenr=65536, device=/dev/nvme0n1p3 --------------------------------------------------------- csum_type 0 (crc32c) csum_size 4 csum 0x043ea018 [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid 90e9d74c-3606-4028-9e72-c10e76f44a7c metadata_uuid 90e9d74c-3606-4028-9e72-c10e76f44a7c label data generation 49 root 8612052992 sys_array_size 97 chunk_root_generation 46 root_level 1 chunk_root 1048576 chunk_root_level 1 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 188743680000 bytes_used 182011633664 sectorsize 4096 nodesize 16384 leafsize (deprecated) 16384 stripesize 4096 root_dir 6 num_devices 1 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0x161 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation 48 uuid_tree_generation 48 dev_item.uuid e2815a2c-6ec8-45c6-baae-7f429a5f0f78 dev_item.fsid 90e9d74c-3606-4028-9e72-c10e76f44a7c [match] dev_item.type 0 dev_item.total_bytes 188743680000 dev_item.bytes_used 184704565248 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 0 sys_chunk_array[2048]: item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 1048576) length 4194304 owner 2 stripe_len 65536 type SYSTEM io_align 4096 io_width 4096 sector_size 4096 num_stripes 1 sub_stripes 0 stripe 0 devid 1 offset 1048576 dev_uuid e2815a2c-6ec8-45c6-baae-7f429a5f0f78 backup_roots[4]: backup 0: backup_tree_root: 8612052992 gen: 49 level: 1 backup_chunk_root: 1048576 gen: 46 level: 1 backup_extent_root: 8612069376 gen: 49 level: 1 backup_fs_root: 8852570112 gen: 47 level: 2 backup_dev_root: 8843755520 gen: 46 level: 0 backup_csum_root: 8853471232 gen: 48 level: 2 backup_total_bytes: 188743680000 backup_bytes_used: 182011633664 backup_num_devices: 1 backup 1: backup_tree_root: 8852389888 gen: 46 level: 1 backup_chunk_root: 1048576 gen: 46 level: 1 backup_extent_root: 8843722752 gen: 46 level: 1 backup_fs_root: 8842969088 gen: 46 level: 2 backup_dev_root: 8843755520 gen: 46 level: 0 backup_csum_root: 8843018240 gen: 46 level: 2 backup_total_bytes: 188743680000 backup_bytes_used: 182011633664 backup_num_devices: 1 backup 2: backup_tree_root: 8853127168 gen: 47 level: 1 backup_chunk_root: 1048576 gen: 46 level: 1 backup_extent_root: 8852865024 gen: 47 level: 1 backup_fs_root: 8852570112 gen: 47 level: 2 backup_dev_root: 8843755520 gen: 46 level: 0 backup_csum_root: 8853192704 gen: 47 level: 2 backup_total_bytes: 188743680000 backup_bytes_used: 182011633664 backup_num_devices: 1 backup 3: backup_tree_root: 8853389312 gen: 48 level: 1 backup_chunk_root: 1048576 gen: 46 level: 1 backup_extent_root: 8853405696 gen: 48 level: 1 backup_fs_root: 8852570112 gen: 47 level: 2 backup_dev_root: 8843755520 gen: 46 level: 0 backup_csum_root: 8853471232 gen: 48 level: 2 backup_total_bytes: 188743680000 backup_bytes_used: 182011633664 backup_num_devices: 1 $> btrfs insp dump-t -d /dev/nvme0n1p3 btrfs-progs v5.6 checksum verify failed on 1048576 found 00000067 wanted 0000006E checksum verify failed on 1048576 found 00000067 wanted 0000006E bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 ERROR: cannot read chunk root ERROR: unable to open /dev/nvme0n1p3 As Andrei Borzenko has stated it is indeed the third superblock: $> btrfs insp dump-super -a /dev/nvme0n1p3 superblock: bytenr=65536, device=/dev/nvme0n1p3 --------------------------------------------------------- csum_type 0 (crc32c) csum_size 4 csum 0x043ea018 [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid 90e9d74c-3606-4028-9e72-c10e76f44a7c metadata_uuid 90e9d74c-3606-4028-9e72-c10e76f44a7c label data generation 49 root 8612052992 sys_array_size 97 chunk_root_generation 46 root_level 1 chunk_root 1048576 chunk_root_level 1 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 188743680000 bytes_used 182011633664 sectorsize 4096 nodesize 16384 leafsize (deprecated) 16384 stripesize 4096 root_dir 6 num_devices 1 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0x161 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation 48 uuid_tree_generation 48 dev_item.uuid e2815a2c-6ec8-45c6-baae-7f429a5f0f78 dev_item.fsid 90e9d74c-3606-4028-9e72-c10e76f44a7c [match] dev_item.type 0 dev_item.total_bytes 188743680000 dev_item.bytes_used 184704565248 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 0 superblock: bytenr=67108864, device=/dev/nvme0n1p3 --------------------------------------------------------- csum_type 0 (crc32c) csum_size 4 csum 0xa45f88d6 [match] bytenr 67108864 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid 90e9d74c-3606-4028-9e72-c10e76f44a7c metadata_uuid 90e9d74c-3606-4028-9e72-c10e76f44a7c label data generation 49 root 8612052992 sys_array_size 97 chunk_root_generation 46 root_level 1 chunk_root 1048576 chunk_root_level 1 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 188743680000 bytes_used 182011633664 sectorsize 4096 nodesize 16384 leafsize (deprecated) 16384 stripesize 4096 root_dir 6 num_devices 1 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0x161 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation 48 uuid_tree_generation 48 dev_item.uuid e2815a2c-6ec8-45c6-baae-7f429a5f0f78 dev_item.fsid 90e9d74c-3606-4028-9e72-c10e76f44a7c [match] dev_item.type 0 dev_item.total_bytes 188743680000 dev_item.bytes_used 184704565248 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 0 superblock: bytenr=274877906944, device=/dev/nvme0n1p3 --------------------------------------------------------- ERROR: bad magic on superblock on /dev/nvme0n1p3 at 274877906944 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Help needed to recover from partition resize/move 2020-04-26 6:23 ` Yegor Yegorov @ 2020-04-26 7:36 ` Chris Murphy 2020-04-26 10:03 ` Andrei Borzenkov 0 siblings, 1 reply; 9+ messages in thread From: Chris Murphy @ 2020-04-26 7:36 UTC (permalink / raw) To: Yegor Yegorov; +Cc: Chris Murphy, Btrfs BTRFS, Andrei Borzenkov (sorry, reply all this time) On Sun, Apr 26, 2020 at 12:23 AM Yegor Yegorov <gochkin@gmail.com> wrote: > $> btrfs insp dump-s -f /dev/nvme0n1p3 > > chunk_root 1048576 > chunk_root_level 1 > sys_chunk_array[2048]: > item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 1048576) > length 4194304 owner 2 stripe_len 65536 type SYSTEM > io_align 4096 io_width 4096 sector_size 4096 > num_stripes 1 sub_stripes 0 > stripe 0 devid 1 offset 1048576 > dev_uuid e2815a2c-6ec8-45c6-baae-7f429a5f0f78 Super and backups say the system chunk is at 1048576, and root is at 8612052992. btrfs insp dump-t -b 8612052992 btrfs insp dump-t -b 1048576 > superblock: bytenr=274877906944, device=/dev/nvme0n1p3 > --------------------------------------------------------- > ERROR: bad magic on superblock on /dev/nvme0n1p3 at 274877906944 ? OK but why does it even go looking for this 3rd super? A file system of this size doesn't have a 3rd super, which appears at 256G. There's no dmesg for the resize? This should report the block group changes that happen as part of the resize; and also the fs size change; and also the partition map change. And if it is rebooted, then dump-super shouldn't be looking for a 3rd super. What do you get for 'lsblk' -- Chris Murphy ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Help needed to recover from partition resize/move 2020-04-26 7:36 ` Chris Murphy @ 2020-04-26 10:03 ` Andrei Borzenkov 0 siblings, 0 replies; 9+ messages in thread From: Andrei Borzenkov @ 2020-04-26 10:03 UTC (permalink / raw) To: Chris Murphy, Yegor Yegorov; +Cc: Btrfs BTRFS 26.04.2020 10:36, Chris Murphy пишет: >> superblock: bytenr=274877906944, device=/dev/nvme0n1p3 >> --------------------------------------------------------- >> ERROR: bad magic on superblock on /dev/nvme0n1p3 at 274877906944 > > ? OK but why does it even go looking for this 3rd super? A file system > of this size doesn't have a 3rd super, which appears at 256G. > > There's no dmesg for the resize? This should report the block group > changes that happen as part of the resize; and also the fs size > change; and also the partition map change. And if it is rebooted, then > dump-super shouldn't be looking for a 3rd super. > Most likely it is code bug. The condition is if (ret == 0 && errno == 0) but errno is not guaranteed to be reset to zero after previous errors. Linux errno(3): The value in errno is significant only when the return value of the call indicated an error (i.e., -1 from most system calls; -1 or NULL from most library functions); a function that succeeds is allowed to change errno. The value of errno is never set to zero by any system call or library function. And pread64(2) Note that is not an error for a successful call to transfer fewer bytes than requested (see read(2) and write(2)). On error, -1 is returned and errno is set to indicate the cause of the error. So errno check here is entirely redundant, the only case when pread64 returns 0 is reading past EOF. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Help needed to recover from partition resize/move 2020-04-25 10:24 Help needed to recover from partition resize/move Yegor Yegorov 2020-04-25 20:05 ` Chris Murphy @ 2020-04-26 11:04 ` Ferry Toth 1 sibling, 0 replies; 9+ messages in thread From: Ferry Toth @ 2020-04-26 11:04 UTC (permalink / raw) To: Yegor Yegorov, linux-btrfs Op 25-04-2020 om 12:24 schreef Yegor Yegorov: > Hi, I have been stupid enough to try to move and extend my btrfs > partition using a GUI software of my distro. The operation ended with > an error. From the logs of the operation, I understood that the > movement of the partition succeeded, but some finishing operation is > failed. I don't have this log anymore, so I can't provide further > information on that. Which GUI software did you use? I had already 2x (yeah, but to my defense there was a long time in between) a similar problem with partitionmanager (KDE Partition Manager). In that case I only did a move (overlapping), which took hours. When it apparently succeeded and I tried to mount btrfs complains similar to your tail below.. In both cases the fix was the same: I restored partition start/end with fdisk - and that was all. No data was lost. Then used gparted (Gnome Partition Manager) to do the same - that worked. Crazy. > Now I ended up with btrfs partition that can't be mounted. Here the > output of the various system and btrfs tools: > > $> mount -t btrfs /dev/nvme0n1p3 /mnt/ > mount: /mnt/: wrong fs type, bad option, bad superblock on > /dev/nvme0n1p3, missing codepage or helper program, or other error. > > $>dmesg | tail > [11637.931751] BTRFS info (device nvme0n1p3): disk space caching is enabled > [11637.931754] BTRFS info (device nvme0n1p3): has skinny extents > [11637.936339] BTRFS error (device nvme0n1p3): bad tree block start, > want 1048576 have 6267530653245814412 > [11637.936350] BTRFS error (device nvme0n1p3): failed to read chunk root > [11637.950289] BTRFS error (device nvme0n1p3): open_ctree failed > [11637.950893] audit: type=1106 audit(1587809374.388:663): pid=14229 > uid=0 auid=1000 ses=2 msg='op=PAM:session_close > grantors=pam_limits,pam_unix,pam_permit acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > [11637.951039] audit: type=1104 audit(1587809374.388:664): pid=14229 > uid=0 auid=1000 ses=2 msg='op=PAM:setcred > grantors=pam_unix,pam_permit,pam_env acct="root" exe="/usr/bin/sudo" > hostname=? addr=? terminal=/dev/pts/1 res=success' > [11674.981082] audit: type=1101 audit(1587809411.415:665): pid=14277 > uid=1000 auid=1000 ses=2 msg='op=PAM:accounting > grantors=pam_unix,pam_permit,pam_time acct="go4a" exe="/usr/bin/sudo" > hostname=? addr=? terminal=/dev/pts/1 res=success' > [11674.981423] audit: type=1110 audit(1587809411.415:666): pid=14277 > uid=0 auid=1000 ses=2 msg='op=PAM:setcred > grantors=pam_unix,pam_permit,pam_env acct="root" exe="/usr/bin/sudo" > hostname=? addr=? terminal=/dev/pts/1 res=success' > [11674.985959] audit: type=1105 audit(1587809411.422:667): pid=14277 > uid=0 auid=1000 ses=2 msg='op=PAM:session_open > grantors=pam_limits,pam_unix,pam_permit acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > > $> btrfs check /dev/nvme0n1p3 > Opening filesystem to check... > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > ERROR: cannot open file system > > $> btrfs restore /dev/nvme0n1p3 /mnt/ > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > Could not open root, trying backup super > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > Could not open root, trying backup super > ERROR: superblock bytenr 274877906944 is larger than device size 188743680000 > Could not open root, trying backup super > > $> btrfs rescue chunk-recover /dev/nvme0n1p3 > Scanning: DONE in dev0 > Check chunks successfully with no orphans > Chunk tree recovered successfully > > $>btrfs rescue super-recover /dev/nvme0n1p3 > All supers are valid, no need to recover > > $>btrfs rescue zero-log /dev/nvme0n1p3 > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > ERROR: could not open ctree > > $>btrfs-find-root /dev/nvme0n1p3 > WARNING: cannot read chunk root, continue anyway > Superblock thinks the generation is 49 > Superblock thinks the level is 1 > > $>btrfs check --repair /dev/nvme0n1p3 > Starting repair. > Opening filesystem to check... > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > ERROR: cannot open file system > > > $> btrfs check --repair --init-csum-tree --init-extent-tree /dev/nvme0n1p3 > Starting repair. > Opening filesystem to check... > checksum verify failed on 1048576 found 00000067 wanted 0000006E > checksum verify failed on 1048576 found 00000067 wanted 0000006E > bad tree block 1048576, bytenr mismatch, want=1048576, have=6267530653245814412 > ERROR: cannot read chunk root > ERROR: cannot open file system > > > > > $> uname -a > Linux go4a-HP-Spectre 5.7.0-1-MANJARO #1 SMP PREEMPT Tue Apr 21 > 20:48:43 UTC 2020 x86_64 GNU/Linux > > $> btrfs --version > btrfs-progs v5.6 > > $> btrfs fi show > Label: none uuid: 1e1d4296-9d34-4070-9d8b-18d5dfbad486 > Total devices 1 FS bytes used 85.02GiB > devid 1 size 97.17GiB used 97.17GiB path /dev/nvme0n1p7 > > Label: 'data' uuid: 90e9d74c-3606-4028-9e72-c10e76f44a7c > Total devices 1 FS bytes used 169.51GiB > devid 1 size 175.78GiB used 172.02GiB path /dev/nvme0n1p3 > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-04-26 11:20 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-25 10:24 Help needed to recover from partition resize/move Yegor Yegorov 2020-04-25 20:05 ` Chris Murphy 2020-04-25 21:54 ` Yegor Yegorov 2020-04-26 0:56 ` Chris Murphy 2020-04-26 5:58 ` Andrei Borzenkov 2020-04-26 6:23 ` Yegor Yegorov 2020-04-26 7:36 ` Chris Murphy 2020-04-26 10:03 ` Andrei Borzenkov 2020-04-26 11:04 ` Ferry Toth
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.