* 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.