* btrfs partition is broken, cannot restore anything
@ 2018-11-01 20:40 Attila Vangel
2018-11-02 0:26 ` Qu Wenruo
2018-11-05 18:01 ` Attila Vangel
0 siblings, 2 replies; 8+ messages in thread
From: Attila Vangel @ 2018-11-01 20:40 UTC (permalink / raw)
To: linux-btrfs
Hi,
Somehow my btrfs partition got broken. I use Arch, so my kernel is
quite new (4.18.x).
I don't remember exactly the sequence of events. At some point it was
accessible in read-only, but unfortunately I did not take backup
immediately. dmesg log from that time:
[ 62.602388] BTRFS warning (device nvme0n1p2): block group
103923318784 has wrong amount of free space
[ 62.602390] BTRFS warning (device nvme0n1p2): failed to load free
space cache for block group 103923318784, rebuilding it now
[ 108.039188] BTRFS error (device nvme0n1p2): bad tree block start 0 18812026880
[ 108.039227] BTRFS: error (device nvme0n1p2) in
__btrfs_free_extent:7010: errno=-5 IO failure
[ 108.039241] BTRFS info (device nvme0n1p2): forced readonly
[ 108.039250] BTRFS: error (device nvme0n1p2) in
btrfs_run_delayed_refs:3076: errno=-5 IO failure
At the next reboot it failed to mount. Problem may have been that at
some point I booted to another distro with older kernel (4.15.x,
4.14.52) and unfortunately attempted some checks/repairs (?) e.g. from
gparted, and at that time I did not know it could be destructive.
Anyway, currently it fails to mount (even with ro and/or recovery),
btrfs check results in "checksum verify failed" and "bad tree block"
errors, btrfs restore resulted in "We have looped trying to restore
files in" errors for a dozen of paths then exit.
Is there some hope to save data from the filesystem, and if so, how?
BTW I checked some diagnostics commands regarding my SSD with the nvme
client and from that it seems there are no hardware problems.
Your help is highly appreciated.
Cheers,
Attila
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: btrfs partition is broken, cannot restore anything
2018-11-01 20:40 btrfs partition is broken, cannot restore anything Attila Vangel
@ 2018-11-02 0:26 ` Qu Wenruo
2018-11-05 18:01 ` Attila Vangel
1 sibling, 0 replies; 8+ messages in thread
From: Qu Wenruo @ 2018-11-02 0:26 UTC (permalink / raw)
To: Attila Vangel, linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 2372 bytes --]
On 2018/11/2 上午4:40, Attila Vangel wrote:
> Hi,
>
> Somehow my btrfs partition got broken. I use Arch, so my kernel is
> quite new (4.18.x).
> I don't remember exactly the sequence of events. At some point it was
> accessible in read-only, but unfortunately I did not take backup
> immediately. dmesg log from that time:
>
> [ 62.602388] BTRFS warning (device nvme0n1p2): block group
> 103923318784 has wrong amount of free space
> [ 62.602390] BTRFS warning (device nvme0n1p2): failed to load free
> space cache for block group 103923318784, rebuilding it now
> [ 108.039188] BTRFS error (device nvme0n1p2): bad tree block start 0 18812026880
> [ 108.039227] BTRFS: error (device nvme0n1p2) in
> __btrfs_free_extent:7010: errno=-5 IO failure
Normally we shouldn't call __btrfs_free_extent() during mount.
It looks like it's caused by log tree replay.
You could try to mount the fs with -o ro,nologreplay to see if you could
still mount the fs RO without log replay.
If it goes well, at least you could access the files.
> [ 108.039241] BTRFS info (device nvme0n1p2): forced readonly
> [ 108.039250] BTRFS: error (device nvme0n1p2) in
> btrfs_run_delayed_refs:3076: errno=-5 IO failure
>
> At the next reboot it failed to mount. Problem may have been that at
> some point I booted to another distro with older kernel (4.15.x,
> 4.14.52) and unfortunately attempted some checks/repairs (?) e.g. from
> gparted, and at that time I did not know it could be destructive.>
> Anyway, currently it fails to mount (even with ro and/or recovery),
> btrfs check results in "checksum verify failed" and "bad tree block"
> errors,
Full btrfs check result please.
> btrfs restore resulted in "We have looped trying to restore
> files in" errors for a dozen of paths then exit.
So at least btrfs-restore is working.
This normally means the fs is not completely corrupted, and essential
trees are at least OK.
Still need that "btrfs check" output (along with "btrfs check
--mode=lowmem") to determine what to do.
Thanks,
Qu
>
> Is there some hope to save data from the filesystem, and if so, how?
>
> BTW I checked some diagnostics commands regarding my SSD with the nvme
> client and from that it seems there are no hardware problems.
>
> Your help is highly appreciated.
>
> Cheers,
> Attila
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: btrfs partition is broken, cannot restore anything
2018-11-01 20:40 btrfs partition is broken, cannot restore anything Attila Vangel
2018-11-02 0:26 ` Qu Wenruo
@ 2018-11-05 18:01 ` Attila Vangel
2018-11-05 18:10 ` Attila Vangel
2018-11-06 1:28 ` Qu Wenruo
1 sibling, 2 replies; 8+ messages in thread
From: Attila Vangel @ 2018-11-05 18:01 UTC (permalink / raw)
To: linux-btrfs
Hi,
TL;DR: I want to save data from my unmountable btrfs partition.
I saw some commands in another thread "Salvage files from broken btrfs".
I use the most recent Manjaro live (kernel: 4.19.0-3-MANJARO,
btrfs-progs 4.17.1-1) to execute these commands.
$ sudo mount -o ro,nologreplay /dev/nvme0n1p2 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on
/dev/nvme0n1p2, missing codepage or helper program, or other error.
Corresponding lines from dmesg:
[ 1517.772302] BTRFS info (device nvme0n1p2): disabling log replay at mount time
[ 1517.772307] BTRFS info (device nvme0n1p2): disk space caching is enabled
[ 1517.772310] BTRFS info (device nvme0n1p2): has skinny extents
[ 1517.793414] BTRFS error (device nvme0n1p2): bad tree block start,
want 18811453440 have 0
[ 1517.793430] BTRFS error (device nvme0n1p2): failed to read block groups: -5
[ 1517.808619] BTRFS error (device nvme0n1p2): open_ctree failed
$ sudo btrfs-find-root /dev/nvme0n1p2
Superblock thinks the generation is 220524
Superblock thinks the level is 1
Found tree root at 25018368 gen 220524 level 1
Well block 4243456(gen: 220520 level: 1) seems good, but
generation/level doesn't match, want gen: 220524 level: 1
Well block 5259264(gen: 220519 level: 1) seems good, but
generation/level doesn't match, want gen: 220524 level: 1
Well block 4866048(gen: 220518 level: 0) seems good, but
generation/level doesn't match, want gen: 220524 level: 1
$ sudo btrfs ins dump-super -Ffa /dev/nvme0n1p2
superblock: bytenr=65536, device=/dev/nvme0n1p2
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x7956a931 [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 014c9d24-339c-482e-8f06-9284e4a7bc40
label newhome
generation 220524
root 25018368
sys_array_size 97
chunk_root_generation 219209
root_level 1
chunk_root 131072
chunk_root_level 1
log_root 86818816
log_root_transid 0
log_root_level 0
total_bytes 355938074624
bytes_used 344504737792
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 220524
uuid_tree_generation 220524
dev_item.uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
dev_item.fsid 014c9d24-339c-482e-8f06-9284e4a7bc40 [match]
dev_item.type 0
dev_item.total_bytes 355938074624
dev_item.bytes_used 355792322560
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 0)
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 0
dev_uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
backup_roots[4]:
backup 0:
backup_tree_root: 42598400 gen: 220522 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 26460160 gen: 220522 level: 2
backup_fs_root: 51347456 gen: 220523 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 26558464 gen: 220522 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504741888
backup_num_devices: 1
backup 1:
backup_tree_root: 52363264 gen: 220523 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 51806208 gen: 220523 level: 2
backup_fs_root: 51347456 gen: 220523 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 52461568 gen: 220523 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504729600
backup_num_devices: 1
backup 2:
backup_tree_root: 25018368 gen: 220524 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 21479424 gen: 220524 level: 2
backup_fs_root: 53084160 gen: 220524 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 53379072 gen: 220524 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504737792
backup_num_devices: 1
backup 3:
backup_tree_root: 21921792 gen: 220521 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 5570560 gen: 220521 level: 2
backup_fs_root: 4571136 gen: 220521 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 5619712 gen: 220521 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344506957824
backup_num_devices: 1
superblock: bytenr=67108864, device=/dev/nvme0n1p2
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x36d97b1b [match]
bytenr 67108864
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 014c9d24-339c-482e-8f06-9284e4a7bc40
label newhome
generation 220524
root 25018368
sys_array_size 97
chunk_root_generation 219209
root_level 1
chunk_root 131072
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 355938074624
bytes_used 344504737792
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 220524
uuid_tree_generation 220524
dev_item.uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
dev_item.fsid 014c9d24-339c-482e-8f06-9284e4a7bc40 [match]
dev_item.type 0
dev_item.total_bytes 355938074624
dev_item.bytes_used 355792322560
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 0)
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 0
dev_uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
backup_roots[4]:
backup 0:
backup_tree_root: 42598400 gen: 220522 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 26460160 gen: 220522 level: 2
backup_fs_root: 51347456 gen: 220523 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 26558464 gen: 220522 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504741888
backup_num_devices: 1
backup 1:
backup_tree_root: 52363264 gen: 220523 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 51806208 gen: 220523 level: 2
backup_fs_root: 51347456 gen: 220523 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 52461568 gen: 220523 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504729600
backup_num_devices: 1
backup 2:
backup_tree_root: 25018368 gen: 220524 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 21479424 gen: 220524 level: 2
backup_fs_root: 53084160 gen: 220524 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 53379072 gen: 220524 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504737792
backup_num_devices: 1
backup 3:
backup_tree_root: 21921792 gen: 220521 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 5570560 gen: 220521 level: 2
backup_fs_root: 4571136 gen: 220521 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 5619712 gen: 220521 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344506957824
backup_num_devices: 1
superblock: bytenr=274877906944, device=/dev/nvme0n1p2
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0xcb5e2d2a [match]
bytenr 274877906944
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 014c9d24-339c-482e-8f06-9284e4a7bc40
label newhome
generation 220524
root 25018368
sys_array_size 97
chunk_root_generation 219209
root_level 1
chunk_root 131072
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 355938074624
bytes_used 344504737792
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 220524
uuid_tree_generation 220524
dev_item.uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
dev_item.fsid 014c9d24-339c-482e-8f06-9284e4a7bc40 [match]
dev_item.type 0
dev_item.total_bytes 355938074624
dev_item.bytes_used 355792322560
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 0)
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 0
dev_uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
backup_roots[4]:
backup 0:
backup_tree_root: 42598400 gen: 220522 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 26460160 gen: 220522 level: 2
backup_fs_root: 51347456 gen: 220523 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 26558464 gen: 220522 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504741888
backup_num_devices: 1
backup 1:
backup_tree_root: 52363264 gen: 220523 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 51806208 gen: 220523 level: 2
backup_fs_root: 51347456 gen: 220523 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 52461568 gen: 220523 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504729600
backup_num_devices: 1
backup 2:
backup_tree_root: 25018368 gen: 220524 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 21479424 gen: 220524 level: 2
backup_fs_root: 53084160 gen: 220524 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 53379072 gen: 220524 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344504737792
backup_num_devices: 1
backup 3:
backup_tree_root: 21921792 gen: 220521 level: 1
backup_chunk_root: 131072 gen: 219209 level: 1
backup_extent_root: 5570560 gen: 220521 level: 2
backup_fs_root: 4571136 gen: 220521 level: 2
backup_dev_root: 4472832 gen: 220520 level: 1
backup_csum_root: 5619712 gen: 220521 level: 2
backup_total_bytes: 355938074624
backup_bytes_used: 344506957824
backup_num_devices: 1
If I understood correctly, somehow it is possible to use this data to
parametrize btrfs restore to save the files from the partition.
Could you please help how to do it in this case? I am not familiar
with these technical terms in the outputs.
Thanks in advance!
Cheers,
Attila
On Thu, Nov 1, 2018 at 8:40 PM Attila Vangel <vangel.attila@gmail.com> wrote:
>
> Hi,
>
> Somehow my btrfs partition got broken. I use Arch, so my kernel is
> quite new (4.18.x).
> I don't remember exactly the sequence of events. At some point it was
> accessible in read-only, but unfortunately I did not take backup
> immediately. dmesg log from that time:
>
> [ 62.602388] BTRFS warning (device nvme0n1p2): block group
> 103923318784 has wrong amount of free space
> [ 62.602390] BTRFS warning (device nvme0n1p2): failed to load free
> space cache for block group 103923318784, rebuilding it now
> [ 108.039188] BTRFS error (device nvme0n1p2): bad tree block start 0 18812026880
> [ 108.039227] BTRFS: error (device nvme0n1p2) in
> __btrfs_free_extent:7010: errno=-5 IO failure
> [ 108.039241] BTRFS info (device nvme0n1p2): forced readonly
> [ 108.039250] BTRFS: error (device nvme0n1p2) in
> btrfs_run_delayed_refs:3076: errno=-5 IO failure
>
> At the next reboot it failed to mount. Problem may have been that at
> some point I booted to another distro with older kernel (4.15.x,
> 4.14.52) and unfortunately attempted some checks/repairs (?) e.g. from
> gparted, and at that time I did not know it could be destructive.
>
> Anyway, currently it fails to mount (even with ro and/or recovery),
> btrfs check results in "checksum verify failed" and "bad tree block"
> errors, btrfs restore resulted in "We have looped trying to restore
> files in" errors for a dozen of paths then exit.
>
> Is there some hope to save data from the filesystem, and if so, how?
>
> BTW I checked some diagnostics commands regarding my SSD with the nvme
> client and from that it seems there are no hardware problems.
>
> Your help is highly appreciated.
>
> Cheers,
> Attila
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: btrfs partition is broken, cannot restore anything
2018-11-05 18:01 ` Attila Vangel
@ 2018-11-05 18:10 ` Attila Vangel
2018-11-06 1:28 ` Qu Wenruo
1 sibling, 0 replies; 8+ messages in thread
From: Attila Vangel @ 2018-11-05 18:10 UTC (permalink / raw)
To: linux-btrfs
Hi,
Stupid gmail has put my email (or Qu's reply? ) to spam, so I just saw
the reply after I sent my reply (gmail asked me whether to remove it
from spam).
Anyway here is the requested output. Thanks for the help!
$ sudo btrfs check /dev/nvme0n1p2
Opening filesystem to check...
checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000
checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000
bad tree block 18811453440, bytenr mismatch, want=18811453440, have=0
ERROR: cannot open file system
$ sudo btrfs check --mode=lowmem /dev/nvme0n1p2
Opening filesystem to check...
checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000
checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000
bad tree block 18811453440, bytenr mismatch, want=18811453440, have=0
ERROR: cannot open file system
Regards,
Attila
On Mon, Nov 5, 2018 at 6:01 PM Attila Vangel <vangel.attila@gmail.com> wrote:
>
> Hi,
>
> TL;DR: I want to save data from my unmountable btrfs partition.
> I saw some commands in another thread "Salvage files from broken btrfs".
> I use the most recent Manjaro live (kernel: 4.19.0-3-MANJARO,
> btrfs-progs 4.17.1-1) to execute these commands.
>
> $ sudo mount -o ro,nologreplay /dev/nvme0n1p2 /mnt
> mount: /mnt: wrong fs type, bad option, bad superblock on
> /dev/nvme0n1p2, missing codepage or helper program, or other error.
>
> Corresponding lines from dmesg:
>
> [ 1517.772302] BTRFS info (device nvme0n1p2): disabling log replay at mount time
> [ 1517.772307] BTRFS info (device nvme0n1p2): disk space caching is enabled
> [ 1517.772310] BTRFS info (device nvme0n1p2): has skinny extents
> [ 1517.793414] BTRFS error (device nvme0n1p2): bad tree block start,
> want 18811453440 have 0
> [ 1517.793430] BTRFS error (device nvme0n1p2): failed to read block groups: -5
> [ 1517.808619] BTRFS error (device nvme0n1p2): open_ctree failed
>
> $ sudo btrfs-find-root /dev/nvme0n1p2
> Superblock thinks the generation is 220524
> Superblock thinks the level is 1
> Found tree root at 25018368 gen 220524 level 1
> Well block 4243456(gen: 220520 level: 1) seems good, but
> generation/level doesn't match, want gen: 220524 level: 1
> Well block 5259264(gen: 220519 level: 1) seems good, but
> generation/level doesn't match, want gen: 220524 level: 1
> Well block 4866048(gen: 220518 level: 0) seems good, but
> generation/level doesn't match, want gen: 220524 level: 1
>
> $ sudo btrfs ins dump-super -Ffa /dev/nvme0n1p2
> superblock: bytenr=65536, device=/dev/nvme0n1p2
> ---------------------------------------------------------
> csum_type 0 (crc32c)
> csum_size 4
> csum 0x7956a931 [match]
> bytenr 65536
> flags 0x1
> ( WRITTEN )
> magic _BHRfS_M [match]
> fsid 014c9d24-339c-482e-8f06-9284e4a7bc40
> label newhome
> generation 220524
> root 25018368
> sys_array_size 97
> chunk_root_generation 219209
> root_level 1
> chunk_root 131072
> chunk_root_level 1
> log_root 86818816
> log_root_transid 0
> log_root_level 0
> total_bytes 355938074624
> bytes_used 344504737792
> 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 220524
> uuid_tree_generation 220524
> dev_item.uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
> dev_item.fsid 014c9d24-339c-482e-8f06-9284e4a7bc40 [match]
> dev_item.type 0
> dev_item.total_bytes 355938074624
> dev_item.bytes_used 355792322560
> 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 0)
> 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 0
> dev_uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
> backup_roots[4]:
> backup 0:
> backup_tree_root: 42598400 gen: 220522 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 26460160 gen: 220522 level: 2
> backup_fs_root: 51347456 gen: 220523 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 26558464 gen: 220522 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504741888
> backup_num_devices: 1
>
> backup 1:
> backup_tree_root: 52363264 gen: 220523 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 51806208 gen: 220523 level: 2
> backup_fs_root: 51347456 gen: 220523 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 52461568 gen: 220523 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504729600
> backup_num_devices: 1
>
> backup 2:
> backup_tree_root: 25018368 gen: 220524 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 21479424 gen: 220524 level: 2
> backup_fs_root: 53084160 gen: 220524 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 53379072 gen: 220524 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504737792
> backup_num_devices: 1
>
> backup 3:
> backup_tree_root: 21921792 gen: 220521 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 5570560 gen: 220521 level: 2
> backup_fs_root: 4571136 gen: 220521 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 5619712 gen: 220521 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344506957824
> backup_num_devices: 1
>
>
> superblock: bytenr=67108864, device=/dev/nvme0n1p2
> ---------------------------------------------------------
> csum_type 0 (crc32c)
> csum_size 4
> csum 0x36d97b1b [match]
> bytenr 67108864
> flags 0x1
> ( WRITTEN )
> magic _BHRfS_M [match]
> fsid 014c9d24-339c-482e-8f06-9284e4a7bc40
> label newhome
> generation 220524
> root 25018368
> sys_array_size 97
> chunk_root_generation 219209
> root_level 1
> chunk_root 131072
> chunk_root_level 1
> log_root 0
> log_root_transid 0
> log_root_level 0
> total_bytes 355938074624
> bytes_used 344504737792
> 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 220524
> uuid_tree_generation 220524
> dev_item.uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
> dev_item.fsid 014c9d24-339c-482e-8f06-9284e4a7bc40 [match]
> dev_item.type 0
> dev_item.total_bytes 355938074624
> dev_item.bytes_used 355792322560
> 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 0)
> 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 0
> dev_uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
> backup_roots[4]:
> backup 0:
> backup_tree_root: 42598400 gen: 220522 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 26460160 gen: 220522 level: 2
> backup_fs_root: 51347456 gen: 220523 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 26558464 gen: 220522 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504741888
> backup_num_devices: 1
>
> backup 1:
> backup_tree_root: 52363264 gen: 220523 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 51806208 gen: 220523 level: 2
> backup_fs_root: 51347456 gen: 220523 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 52461568 gen: 220523 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504729600
> backup_num_devices: 1
>
> backup 2:
> backup_tree_root: 25018368 gen: 220524 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 21479424 gen: 220524 level: 2
> backup_fs_root: 53084160 gen: 220524 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 53379072 gen: 220524 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504737792
> backup_num_devices: 1
>
> backup 3:
> backup_tree_root: 21921792 gen: 220521 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 5570560 gen: 220521 level: 2
> backup_fs_root: 4571136 gen: 220521 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 5619712 gen: 220521 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344506957824
> backup_num_devices: 1
>
>
> superblock: bytenr=274877906944, device=/dev/nvme0n1p2
> ---------------------------------------------------------
> csum_type 0 (crc32c)
> csum_size 4
> csum 0xcb5e2d2a [match]
> bytenr 274877906944
> flags 0x1
> ( WRITTEN )
> magic _BHRfS_M [match]
> fsid 014c9d24-339c-482e-8f06-9284e4a7bc40
> label newhome
> generation 220524
> root 25018368
> sys_array_size 97
> chunk_root_generation 219209
> root_level 1
> chunk_root 131072
> chunk_root_level 1
> log_root 0
> log_root_transid 0
> log_root_level 0
> total_bytes 355938074624
> bytes_used 344504737792
> 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 220524
> uuid_tree_generation 220524
> dev_item.uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
> dev_item.fsid 014c9d24-339c-482e-8f06-9284e4a7bc40 [match]
> dev_item.type 0
> dev_item.total_bytes 355938074624
> dev_item.bytes_used 355792322560
> 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 0)
> 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 0
> dev_uuid 05fe6ce8-1f2d-41ba-a367-cbdb8f06ffd3
> backup_roots[4]:
> backup 0:
> backup_tree_root: 42598400 gen: 220522 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 26460160 gen: 220522 level: 2
> backup_fs_root: 51347456 gen: 220523 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 26558464 gen: 220522 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504741888
> backup_num_devices: 1
>
> backup 1:
> backup_tree_root: 52363264 gen: 220523 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 51806208 gen: 220523 level: 2
> backup_fs_root: 51347456 gen: 220523 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 52461568 gen: 220523 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504729600
> backup_num_devices: 1
>
> backup 2:
> backup_tree_root: 25018368 gen: 220524 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 21479424 gen: 220524 level: 2
> backup_fs_root: 53084160 gen: 220524 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 53379072 gen: 220524 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344504737792
> backup_num_devices: 1
>
> backup 3:
> backup_tree_root: 21921792 gen: 220521 level: 1
> backup_chunk_root: 131072 gen: 219209 level: 1
> backup_extent_root: 5570560 gen: 220521 level: 2
> backup_fs_root: 4571136 gen: 220521 level: 2
> backup_dev_root: 4472832 gen: 220520 level: 1
> backup_csum_root: 5619712 gen: 220521 level: 2
> backup_total_bytes: 355938074624
> backup_bytes_used: 344506957824
> backup_num_devices: 1
>
> If I understood correctly, somehow it is possible to use this data to
> parametrize btrfs restore to save the files from the partition.
> Could you please help how to do it in this case? I am not familiar
> with these technical terms in the outputs.
> Thanks in advance!
>
> Cheers,
> Attila
>
> On Thu, Nov 1, 2018 at 8:40 PM Attila Vangel <vangel.attila@gmail.com> wrote:
> >
> > Hi,
> >
> > Somehow my btrfs partition got broken. I use Arch, so my kernel is
> > quite new (4.18.x).
> > I don't remember exactly the sequence of events. At some point it was
> > accessible in read-only, but unfortunately I did not take backup
> > immediately. dmesg log from that time:
> >
> > [ 62.602388] BTRFS warning (device nvme0n1p2): block group
> > 103923318784 has wrong amount of free space
> > [ 62.602390] BTRFS warning (device nvme0n1p2): failed to load free
> > space cache for block group 103923318784, rebuilding it now
> > [ 108.039188] BTRFS error (device nvme0n1p2): bad tree block start 0 18812026880
> > [ 108.039227] BTRFS: error (device nvme0n1p2) in
> > __btrfs_free_extent:7010: errno=-5 IO failure
> > [ 108.039241] BTRFS info (device nvme0n1p2): forced readonly
> > [ 108.039250] BTRFS: error (device nvme0n1p2) in
> > btrfs_run_delayed_refs:3076: errno=-5 IO failure
> >
> > At the next reboot it failed to mount. Problem may have been that at
> > some point I booted to another distro with older kernel (4.15.x,
> > 4.14.52) and unfortunately attempted some checks/repairs (?) e.g. from
> > gparted, and at that time I did not know it could be destructive.
> >
> > Anyway, currently it fails to mount (even with ro and/or recovery),
> > btrfs check results in "checksum verify failed" and "bad tree block"
> > errors, btrfs restore resulted in "We have looped trying to restore
> > files in" errors for a dozen of paths then exit.
> >
> > Is there some hope to save data from the filesystem, and if so, how?
> >
> > BTW I checked some diagnostics commands regarding my SSD with the nvme
> > client and from that it seems there are no hardware problems.
> >
> > Your help is highly appreciated.
> >
> > Cheers,
> > Attila
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: btrfs partition is broken, cannot restore anything
2018-11-05 18:01 ` Attila Vangel
2018-11-05 18:10 ` Attila Vangel
@ 2018-11-06 1:28 ` Qu Wenruo
2018-11-06 8:17 ` Attila Vangel
1 sibling, 1 reply; 8+ messages in thread
From: Qu Wenruo @ 2018-11-06 1:28 UTC (permalink / raw)
To: Attila Vangel, linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 4256 bytes --]
On 2018/11/6 上午2:01, Attila Vangel wrote:
> Hi,
>
> TL;DR: I want to save data from my unmountable btrfs partition.
> I saw some commands in another thread "Salvage files from broken btrfs".
> I use the most recent Manjaro live (kernel: 4.19.0-3-MANJARO,
> btrfs-progs 4.17.1-1) to execute these commands.
>
> $ sudo mount -o ro,nologreplay /dev/nvme0n1p2 /mnt
> mount: /mnt: wrong fs type, bad option, bad superblock on
> /dev/nvme0n1p2, missing codepage or helper program, or other error.
>
> Corresponding lines from dmesg:
>
> [ 1517.772302] BTRFS info (device nvme0n1p2): disabling log replay at mount time
> [ 1517.772307] BTRFS info (device nvme0n1p2): disk space caching is enabled
> [ 1517.772310] BTRFS info (device nvme0n1p2): has skinny extents
> [ 1517.793414] BTRFS error (device nvme0n1p2): bad tree block start,
> want 18811453440 have 0
> [ 1517.793430] BTRFS error (device nvme0n1p2): failed to read block groups: -5
> [ 1517.808619] BTRFS error (device nvme0n1p2): open_ctree failed
Extent tree corrupted.
If it's the only problem, btrfs-restore should be able to salvage data.
>
> $ sudo btrfs-find-root /dev/nvme0n1p2
No, that's not what you need.
> Superblock thinks the generation is 220524
> Superblock thinks the level is 1
> Found tree root at 25018368 gen 220524 level 1
> Well block 4243456(gen: 220520 level: 1) seems good, but
> generation/level doesn't match, want gen: 220524 level: 1
> Well block 5259264(gen: 220519 level: 1) seems good, but
> generation/level doesn't match, want gen: 220524 level: 1
> Well block 4866048(gen: 220518 level: 0) seems good, but
> generation/level doesn't match, want gen: 220524 level: 1
>
> $ sudo btrfs ins dump-super -Ffa /dev/nvme0n1p2
> superblock: bytenr=65536, device=/dev/nvme0n1p2
[snip]
>
> If I understood correctly, somehow it is possible to use this data to
> parametrize btrfs restore to save the files from the partition.
None of the output is really helpful.
In your case, your extent tree is corrupted, thus kernel will refuse to
mount (even RO).
You should run "btrfs check" on the fs to see if btrfs can check fs tree.
If not, then go directly to "btrfs restore".
Thanks,
Qu
> Could you please help how to do it in this case? I am not familiar
> with these technical terms in the outputs.
> Thanks in advance!
>
> Cheers,
> Attila
>
> On Thu, Nov 1, 2018 at 8:40 PM Attila Vangel <vangel.attila@gmail.com> wrote:
>>
>> Hi,
>>
>> Somehow my btrfs partition got broken. I use Arch, so my kernel is
>> quite new (4.18.x).
>> I don't remember exactly the sequence of events. At some point it was
>> accessible in read-only, but unfortunately I did not take backup
>> immediately. dmesg log from that time:
>>
>> [ 62.602388] BTRFS warning (device nvme0n1p2): block group
>> 103923318784 has wrong amount of free space
>> [ 62.602390] BTRFS warning (device nvme0n1p2): failed to load free
>> space cache for block group 103923318784, rebuilding it now
>> [ 108.039188] BTRFS error (device nvme0n1p2): bad tree block start 0 18812026880
>> [ 108.039227] BTRFS: error (device nvme0n1p2) in
>> __btrfs_free_extent:7010: errno=-5 IO failure
>> [ 108.039241] BTRFS info (device nvme0n1p2): forced readonly
>> [ 108.039250] BTRFS: error (device nvme0n1p2) in
>> btrfs_run_delayed_refs:3076: errno=-5 IO failure
>>
>> At the next reboot it failed to mount. Problem may have been that at
>> some point I booted to another distro with older kernel (4.15.x,
>> 4.14.52) and unfortunately attempted some checks/repairs (?) e.g. from
>> gparted, and at that time I did not know it could be destructive.
>>
>> Anyway, currently it fails to mount (even with ro and/or recovery),
>> btrfs check results in "checksum verify failed" and "bad tree block"
>> errors, btrfs restore resulted in "We have looped trying to restore
>> files in" errors for a dozen of paths then exit.
>>
>> Is there some hope to save data from the filesystem, and if so, how?
>>
>> BTW I checked some diagnostics commands regarding my SSD with the nvme
>> client and from that it seems there are no hardware problems.
>>
>> Your help is highly appreciated.
>>
>> Cheers,
>> Attila
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: btrfs partition is broken, cannot restore anything
2018-11-06 1:28 ` Qu Wenruo
@ 2018-11-06 8:17 ` Attila Vangel
2018-11-06 8:22 ` Qu Wenruo
0 siblings, 1 reply; 8+ messages in thread
From: Attila Vangel @ 2018-11-06 8:17 UTC (permalink / raw)
To: quwenruo.btrfs; +Cc: linux-btrfs
Hi Qu,
Thanks again for the help.
In my case:
$ sudo btrfs check /dev/nvme0n1p2
Opening filesystem to check...
checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000
checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000
bad tree block 18811453440, bytenr mismatch, want=18811453440, have=0
ERROR: cannot open file system
(same with --mode=lowmem).
However "btrfs restore" seems to work! (did not have time for the
actual run yet)
What confused me about "btrds restore" is when I ran a dry run, it
just output about a dozen errors about some files, and I thought
that's it, no files can be restored.
Today I tried it with other options, especially -v shown me that the
majority of the files can be restored. I consider myself an
intermediate GNU plus Linux user, yet given the stressful situation
and being a first time user (btrfs n00b) I missed experimenting with
the -v option.
So I propose that "btrs restore" should always print a summary line at
the end to make it more user friendly (e.g. for the first time users).
Something like this:
x files restored in y directories[, total size of files is z <human
readable unit e.g. GB>]. Use -v command line option for more
information.
The part in square bracket is optional / nice to have, might be useful
e.g. to estimate the required free space in the target filesystem.
Cheers,
Attila
On Tue, Nov 6, 2018 at 2:28 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> On 2018/11/6 上午2:01, Attila Vangel wrote:
> > Hi,
> >
> > TL;DR: I want to save data from my unmountable btrfs partition.
> > I saw some commands in another thread "Salvage files from broken btrfs".
> > I use the most recent Manjaro live (kernel: 4.19.0-3-MANJARO,
> > btrfs-progs 4.17.1-1) to execute these commands.
> >
> > $ sudo mount -o ro,nologreplay /dev/nvme0n1p2 /mnt
> > mount: /mnt: wrong fs type, bad option, bad superblock on
> > /dev/nvme0n1p2, missing codepage or helper program, or other error.
> >
> > Corresponding lines from dmesg:
> >
> > [ 1517.772302] BTRFS info (device nvme0n1p2): disabling log replay at mount time
> > [ 1517.772307] BTRFS info (device nvme0n1p2): disk space caching is enabled
> > [ 1517.772310] BTRFS info (device nvme0n1p2): has skinny extents
> > [ 1517.793414] BTRFS error (device nvme0n1p2): bad tree block start,
> > want 18811453440 have 0
> > [ 1517.793430] BTRFS error (device nvme0n1p2): failed to read block groups: -5
> > [ 1517.808619] BTRFS error (device nvme0n1p2): open_ctree failed
>
> Extent tree corrupted.
>
> If it's the only problem, btrfs-restore should be able to salvage data.
>
> >
> > $ sudo btrfs-find-root /dev/nvme0n1p2
>
> No, that's not what you need.
>
> > Superblock thinks the generation is 220524
> > Superblock thinks the level is 1
> > Found tree root at 25018368 gen 220524 level 1
> > Well block 4243456(gen: 220520 level: 1) seems good, but
> > generation/level doesn't match, want gen: 220524 level: 1
> > Well block 5259264(gen: 220519 level: 1) seems good, but
> > generation/level doesn't match, want gen: 220524 level: 1
> > Well block 4866048(gen: 220518 level: 0) seems good, but
> > generation/level doesn't match, want gen: 220524 level: 1
> >
> > $ sudo btrfs ins dump-super -Ffa /dev/nvme0n1p2
> > superblock: bytenr=65536, device=/dev/nvme0n1p2
> [snip]
> >
> > If I understood correctly, somehow it is possible to use this data to
> > parametrize btrfs restore to save the files from the partition.
>
> None of the output is really helpful.
>
> In your case, your extent tree is corrupted, thus kernel will refuse to
> mount (even RO).
>
> You should run "btrfs check" on the fs to see if btrfs can check fs tree.
> If not, then go directly to "btrfs restore".
>
> Thanks,
> Qu
>
> > Could you please help how to do it in this case? I am not familiar
> > with these technical terms in the outputs.
> > Thanks in advance!
> >
> > Cheers,
> > Attila
> >
> > On Thu, Nov 1, 2018 at 8:40 PM Attila Vangel <vangel.attila@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> Somehow my btrfs partition got broken. I use Arch, so my kernel is
> >> quite new (4.18.x).
> >> I don't remember exactly the sequence of events. At some point it was
> >> accessible in read-only, but unfortunately I did not take backup
> >> immediately. dmesg log from that time:
> >>
> >> [ 62.602388] BTRFS warning (device nvme0n1p2): block group
> >> 103923318784 has wrong amount of free space
> >> [ 62.602390] BTRFS warning (device nvme0n1p2): failed to load free
> >> space cache for block group 103923318784, rebuilding it now
> >> [ 108.039188] BTRFS error (device nvme0n1p2): bad tree block start 0 18812026880
> >> [ 108.039227] BTRFS: error (device nvme0n1p2) in
> >> __btrfs_free_extent:7010: errno=-5 IO failure
> >> [ 108.039241] BTRFS info (device nvme0n1p2): forced readonly
> >> [ 108.039250] BTRFS: error (device nvme0n1p2) in
> >> btrfs_run_delayed_refs:3076: errno=-5 IO failure
> >>
> >> At the next reboot it failed to mount. Problem may have been that at
> >> some point I booted to another distro with older kernel (4.15.x,
> >> 4.14.52) and unfortunately attempted some checks/repairs (?) e.g. from
> >> gparted, and at that time I did not know it could be destructive.
> >>
> >> Anyway, currently it fails to mount (even with ro and/or recovery),
> >> btrfs check results in "checksum verify failed" and "bad tree block"
> >> errors, btrfs restore resulted in "We have looped trying to restore
> >> files in" errors for a dozen of paths then exit.
> >>
> >> Is there some hope to save data from the filesystem, and if so, how?
> >>
> >> BTW I checked some diagnostics commands regarding my SSD with the nvme
> >> client and from that it seems there are no hardware problems.
> >>
> >> Your help is highly appreciated.
> >>
> >> Cheers,
> >> Attila
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: btrfs partition is broken, cannot restore anything
2018-11-06 8:17 ` Attila Vangel
@ 2018-11-06 8:22 ` Qu Wenruo
2018-11-06 11:17 ` Attila Vangel
0 siblings, 1 reply; 8+ messages in thread
From: Qu Wenruo @ 2018-11-06 8:22 UTC (permalink / raw)
To: Attila Vangel; +Cc: linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 6472 bytes --]
On 2018/11/6 下午4:17, Attila Vangel wrote:
> Hi Qu,
>
> Thanks again for the help.
> In my case:
>
> $ sudo btrfs check /dev/nvme0n1p2
> Opening filesystem to check...
> checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000
> checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000
> bad tree block 18811453440, bytenr mismatch, want=18811453440, have=0
> ERROR: cannot open file system
As expected, since extent tree is corrupted, btrfs check can't do much help.
This is definitely something we could enhance, although it will take a
long time for btrfs-progs to handle such case, then some super hard
kernel mount option for kernel to do pure RO mount.
>
> (same with --mode=lowmem).
>
> However "btrfs restore" seems to work! (did not have time for the
> actual run yet)
>
> What confused me about "btrds restore" is when I ran a dry run, it
> just output about a dozen errors about some files, and I thought
> that's it, no files can be restored.
> Today I tried it with other options, especially -v shown me that the
> majority of the files can be restored. I consider myself an
> intermediate GNU plus Linux user, yet given the stressful situation
> and being a first time user (btrfs n00b) I missed experimenting with
> the -v option.
>
> So I propose that "btrs restore" should always print a summary line at
> the end to make it more user friendly (e.g. for the first time users).
> Something like this:
>
> x files restored in y directories[, total size of files is z <human
> readable unit e.g. GB>]. Use -v command line option for more
> information.
>
> The part in square bracket is optional / nice to have, might be useful
> e.g. to estimate the required free space in the target filesystem.
Nice idea. Maybe we could enhance btrfs-restore to that direction.
Thanks,
Qu
>
> Cheers,
> Attila
>
> On Tue, Nov 6, 2018 at 2:28 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2018/11/6 上午2:01, Attila Vangel wrote:
>>> Hi,
>>>
>>> TL;DR: I want to save data from my unmountable btrfs partition.
>>> I saw some commands in another thread "Salvage files from broken btrfs".
>>> I use the most recent Manjaro live (kernel: 4.19.0-3-MANJARO,
>>> btrfs-progs 4.17.1-1) to execute these commands.
>>>
>>> $ sudo mount -o ro,nologreplay /dev/nvme0n1p2 /mnt
>>> mount: /mnt: wrong fs type, bad option, bad superblock on
>>> /dev/nvme0n1p2, missing codepage or helper program, or other error.
>>>
>>> Corresponding lines from dmesg:
>>>
>>> [ 1517.772302] BTRFS info (device nvme0n1p2): disabling log replay at mount time
>>> [ 1517.772307] BTRFS info (device nvme0n1p2): disk space caching is enabled
>>> [ 1517.772310] BTRFS info (device nvme0n1p2): has skinny extents
>>> [ 1517.793414] BTRFS error (device nvme0n1p2): bad tree block start,
>>> want 18811453440 have 0
>>> [ 1517.793430] BTRFS error (device nvme0n1p2): failed to read block groups: -5
>>> [ 1517.808619] BTRFS error (device nvme0n1p2): open_ctree failed
>>
>> Extent tree corrupted.
>>
>> If it's the only problem, btrfs-restore should be able to salvage data.
>>
>>>
>>> $ sudo btrfs-find-root /dev/nvme0n1p2
>>
>> No, that's not what you need.
>>
>>> Superblock thinks the generation is 220524
>>> Superblock thinks the level is 1
>>> Found tree root at 25018368 gen 220524 level 1
>>> Well block 4243456(gen: 220520 level: 1) seems good, but
>>> generation/level doesn't match, want gen: 220524 level: 1
>>> Well block 5259264(gen: 220519 level: 1) seems good, but
>>> generation/level doesn't match, want gen: 220524 level: 1
>>> Well block 4866048(gen: 220518 level: 0) seems good, but
>>> generation/level doesn't match, want gen: 220524 level: 1
>>>
>>> $ sudo btrfs ins dump-super -Ffa /dev/nvme0n1p2
>>> superblock: bytenr=65536, device=/dev/nvme0n1p2
>> [snip]
>>>
>>> If I understood correctly, somehow it is possible to use this data to
>>> parametrize btrfs restore to save the files from the partition.
>>
>> None of the output is really helpful.
>>
>> In your case, your extent tree is corrupted, thus kernel will refuse to
>> mount (even RO).
>>
>> You should run "btrfs check" on the fs to see if btrfs can check fs tree.
>> If not, then go directly to "btrfs restore".
>>
>> Thanks,
>> Qu
>>
>>> Could you please help how to do it in this case? I am not familiar
>>> with these technical terms in the outputs.
>>> Thanks in advance!
>>>
>>> Cheers,
>>> Attila
>>>
>>> On Thu, Nov 1, 2018 at 8:40 PM Attila Vangel <vangel.attila@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Somehow my btrfs partition got broken. I use Arch, so my kernel is
>>>> quite new (4.18.x).
>>>> I don't remember exactly the sequence of events. At some point it was
>>>> accessible in read-only, but unfortunately I did not take backup
>>>> immediately. dmesg log from that time:
>>>>
>>>> [ 62.602388] BTRFS warning (device nvme0n1p2): block group
>>>> 103923318784 has wrong amount of free space
>>>> [ 62.602390] BTRFS warning (device nvme0n1p2): failed to load free
>>>> space cache for block group 103923318784, rebuilding it now
>>>> [ 108.039188] BTRFS error (device nvme0n1p2): bad tree block start 0 18812026880
>>>> [ 108.039227] BTRFS: error (device nvme0n1p2) in
>>>> __btrfs_free_extent:7010: errno=-5 IO failure
>>>> [ 108.039241] BTRFS info (device nvme0n1p2): forced readonly
>>>> [ 108.039250] BTRFS: error (device nvme0n1p2) in
>>>> btrfs_run_delayed_refs:3076: errno=-5 IO failure
>>>>
>>>> At the next reboot it failed to mount. Problem may have been that at
>>>> some point I booted to another distro with older kernel (4.15.x,
>>>> 4.14.52) and unfortunately attempted some checks/repairs (?) e.g. from
>>>> gparted, and at that time I did not know it could be destructive.
>>>>
>>>> Anyway, currently it fails to mount (even with ro and/or recovery),
>>>> btrfs check results in "checksum verify failed" and "bad tree block"
>>>> errors, btrfs restore resulted in "We have looped trying to restore
>>>> files in" errors for a dozen of paths then exit.
>>>>
>>>> Is there some hope to save data from the filesystem, and if so, how?
>>>>
>>>> BTW I checked some diagnostics commands regarding my SSD with the nvme
>>>> client and from that it seems there are no hardware problems.
>>>>
>>>> Your help is highly appreciated.
>>>>
>>>> Cheers,
>>>> Attila
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: btrfs partition is broken, cannot restore anything
2018-11-06 8:22 ` Qu Wenruo
@ 2018-11-06 11:17 ` Attila Vangel
0 siblings, 0 replies; 8+ messages in thread
From: Attila Vangel @ 2018-11-06 11:17 UTC (permalink / raw)
To: quwenruo.btrfs; +Cc: linux-btrfs
Hi Qu,
I created an issue for this feature request, so that it is not lost:
https://github.com/kdave/btrfs-progs/issues/153
Thanks for the help again! Now unsubscribing from this list.
Regards,
Attila
On Tue, Nov 6, 2018 at 9:23 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> On 2018/11/6 下午4:17, Attila Vangel wrote:
[snip]
> > So I propose that "btrs restore" should always print a summary line at
> > the end to make it more user friendly (e.g. for the first time users).
> > Something like this:
> >
> > x files restored in y directories[, total size of files is z <human
> > readable unit e.g. GB>]. Use -v command line option for more
> > information.
> >
> > The part in square bracket is optional / nice to have, might be useful
> > e.g. to estimate the required free space in the target filesystem.
>
> Nice idea. Maybe we could enhance btrfs-restore to that direction.
>
> Thanks,
> Qu
[snip]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-11-06 11:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-01 20:40 btrfs partition is broken, cannot restore anything Attila Vangel
2018-11-02 0:26 ` Qu Wenruo
2018-11-05 18:01 ` Attila Vangel
2018-11-05 18:10 ` Attila Vangel
2018-11-06 1:28 ` Qu Wenruo
2018-11-06 8:17 ` Attila Vangel
2018-11-06 8:22 ` Qu Wenruo
2018-11-06 11:17 ` Attila Vangel
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.