* Can't mount RAID-0 btrfs volume
@ 2023-07-01 14:59 yeslow
2023-07-01 18:13 ` Roman Mamedov
0 siblings, 1 reply; 3+ messages in thread
From: yeslow @ 2023-07-01 14:59 UTC (permalink / raw)
To: linux-btrfs@vger.kernel.org
Hello,
I have a dual boot system with Windows 10 Pro and Linux Kubuntu 22.04.
I have created a btrfs raid-0 volume in my Linux system with 2 SSD drives to store not very important files, where the speed is most important. I then use winbtrfs in the Windows 10 system to be able to access the btrfs volume, when using Windows 10.
Everything worked fine for several months until recently. I deleted some files on the btrfs volume in Windows 10, which always worked fine, but this time I noticed that after the file deletion the volume in Linux was not showing the expected free space. When trying to have this fixed, I decided to give it a try by using the command: btrfs check --clear-space-cache v2
Wrong decision, because after that I got a warning message (don't remember which), and the next time I booted my computer the volume was not possible to mount.
Now, when I run the command: sudo btrfs check --readonly /dev/sda1
I get the following:
Opening filesystem to check...
checksum verify failed on 18266193920 wanted 0x34bed84997ecd963 found 0x9ee6d0c7b17903ec
checksum verify failed on 18266193920 wanted 0x0000000000000000 found 0x3e76427c81028f58
checksum verify failed on 18266193920 wanted 0x34bed84997ecd963 found 0x9ee6d0c7b17903ec
bad tree block 18266193920, bytenr mismatch, want=18266193920, have=6237172951202995731
ERROR: cannot read chunk root
ERROR: cannot open file system
I have tried googling these error messages and found this mailing list. I have tried some suggestions found here:
1)
sudo mount -t btrfs -o rescue=all,ro /dev/sda1 /z1
result:
mount: /z1: can't read superblock on /dev/sda1
dmesg:
[23664.424317] BTRFS info (device sda1): using xxhash64 (xxhash64-generic) checksum algorithm
[23664.424349] BTRFS info (device sda1): enabling all of the rescue options
[23664.424355] BTRFS info (device sda1): ignoring data csums
[23664.424360] BTRFS info (device sda1): ignoring bad roots
[23664.424364] BTRFS info (device sda1): disabling log replay at mount time
[23664.424370] BTRFS info (device sda1): disk space caching is enabled
[23664.425981] BTRFS error (device sda1): bad tree block start, mirror 1 want 18266193920 have 6237172951202995731
[23664.426101] BTRFS error (device sda1): bad tree block start, mirror 2 want 18266193920 have 0
[23664.426127] BTRFS error (device sda1): failed to read chunk root
[23664.427009] BTRFS error (device sda1): open_ctree failed
2) sudo btrfs rescue super-recover -v /dev/sda1
result:
All Devices:
Device: id = 2, name = /dev/sde1
Device: id = 1, name = /dev/sda1
Before Recovering:
[All good supers]:
device name = /dev/sde1
superblock bytenr = 65536
device name = /dev/sde1
superblock bytenr = 67108864
device name = /dev/sde1
superblock bytenr = 274877906944
device name = /dev/sda1
superblock bytenr = 65536
device name = /dev/sda1
superblock bytenr = 67108864
device name = /dev/sda1
superblock bytenr = 274877906944
[All bad supers]:
All supers are valid, no need to recover
---
This volume has some files that I would like to recover. Is there any possibility of fixing this, just to allow me to copy the files that I need? Or is the volume completely broken and all data lost, and then I should simply create a new volume again?
My apologies if this is not the right place for asking this, but the only place where google search showed meaningful answers was here.
My thanks in anticipation.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Can't mount RAID-0 btrfs volume
2023-07-01 14:59 Can't mount RAID-0 btrfs volume yeslow
@ 2023-07-01 18:13 ` Roman Mamedov
2023-07-01 19:52 ` yeslow
0 siblings, 1 reply; 3+ messages in thread
From: Roman Mamedov @ 2023-07-01 18:13 UTC (permalink / raw)
To: yeslow; +Cc: linux-btrfs@vger.kernel.org
On Sat, 01 Jul 2023 14:59:11 +0000
yeslow <yeslow@proton.me> wrote:
> I have a dual boot system with Windows 10 Pro and Linux Kubuntu 22.04.
>
> I have created a btrfs raid-0 volume in my Linux system with 2 SSD drives to
> store not very important files, where the speed is most important. I then
> use winbtrfs in the Windows 10 system to be able to access the btrfs volume,
> when using Windows 10.
>
> Everything worked fine for several months until recently. I deleted some
> files on the btrfs volume in Windows 10, which always worked fine, but this
> time I noticed that after the file deletion the volume in Linux was not
> showing the expected free space. When trying to have this fixed, I decided
> to give it a try by using the command: btrfs check --clear-space-cache v2
Could it be that instead of shutting down, you hibernated Windows 10 that time?
As for the recovery options, look into "btrfs restore", that could fetch files
from a damaged filesystem without trying to mount. If it's not damaged too
hard.
--
With respect,
Roman
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Can't mount RAID-0 btrfs volume
2023-07-01 18:13 ` Roman Mamedov
@ 2023-07-01 19:52 ` yeslow
0 siblings, 0 replies; 3+ messages in thread
From: yeslow @ 2023-07-01 19:52 UTC (permalink / raw)
To: Roman Mamedov; +Cc: linux-btrfs@vger.kernel.org
------- Original Message -------
On Saturday, July 1st, 2023 at 8:13 PM, Roman Mamedov <rm@romanrm.net> wrote:
> On Sat, 01 Jul 2023 14:59:11 +0000
> yeslow yeslow@proton.me wrote:
>
> > I have a dual boot system with Windows 10 Pro and Linux Kubuntu 22.04.
> >
> > I have created a btrfs raid-0 volume in my Linux system with 2 SSD drives to
> > store not very important files, where the speed is most important. I then
> > use winbtrfs in the Windows 10 system to be able to access the btrfs volume,
> > when using Windows 10.
> >
> > Everything worked fine for several months until recently. I deleted some
> > files on the btrfs volume in Windows 10, which always worked fine, but this
> > time I noticed that after the file deletion the volume in Linux was not
> > showing the expected free space. When trying to have this fixed, I decided
> > to give it a try by using the command: btrfs check --clear-space-cache v2
>
>
> Could it be that instead of shutting down, you hibernated Windows 10 that time?
No, I have hibernation disabled. The only thing I had changed was setting the option
in winbtrfs nodatacow, which I also was using on the Linux mount.
These were my mount options on Linux: noatime,nosuid,nodev,nofail,ssd,nodatacow
> As for the recovery options, look into "btrfs restore", that could fetch files
> from a damaged filesystem without trying to mount. If it's not damaged too
> hard.
Unfortunately no success... Either I'm not doing it right, or my volume is too damaged:
$ sudo btrfs restore -D /dev/sda1 Music
checksum verify failed on 18266193920 wanted 0x34bed84997ecd963 found 0x9ee6d0c7b17903ec
checksum verify failed on 18266193920 wanted 0x0000000000000000 found 0x3e76427c81028f58
checksum verify failed on 18266193920 wanted 0x34bed84997ecd963 found 0x9ee6d0c7b17903ec
bad tree block 18266193920, bytenr mismatch, want=18266193920, have=6237172951202995731
ERROR: cannot read chunk root
Could not open root, trying backup super
warning, device 2 is missing
warning, device 2 is missing
checksum verify failed on 18266193920 wanted 0x34bed84997ecd963 found 0x9ee6d0c7b17903ec
checksum verify failed on 18266193920 wanted 0x34bed84997ecd963 found 0x9ee6d0c7b17903ec
bad tree block 18266193920, bytenr mismatch, want=18266193920, have=6237172951202995731
ERROR: cannot read chunk root
Could not open root, trying backup super
warning, device 2 is missing
warning, device 2 is missing
checksum verify failed on 18266193920 wanted 0x34bed84997ecd963 found 0x9ee6d0c7b17903ec
checksum verify failed on 18266193920 wanted 0x34bed84997ecd963 found 0x9ee6d0c7b17903ec
bad tree block 18266193920, bytenr mismatch, want=18266193920, have=6237172951202995731
ERROR: cannot read chunk root
Could not open root, trying backup super
I get this device 2 is missing warning, but both devices are available. If I run the command
on the other device (/dev/sed1) I get the same message but saying that device 1 is missing.
---
I also tried to run another command I found on another thread, and it seems much of the details
of the volume are still correct and valid:
$ sudo btrfs inspect-internal dump-super -f /dev/sda1
superblock: bytenr=65536, device=/dev/sda1
---------------------------------------------------------
csum_type 1 (xxhash64)
csum_size 8
csum 0x76e4b856b5f28aeb [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 833d4ef2-375b-4e9e-b2ae-8f0440a74e3e
metadata_uuid 833d4ef2-375b-4e9e-b2ae-8f0440a74e3e
label 1_Public
generation 188499
root 17206902784
sys_array_size 258
chunk_root_generation 188481
root_level 1
chunk_root 18266193920
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 1932735283200
bytes_used 1859603828736
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 2
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x361
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA |
NO_HOLES )
cache_generation 188499
uuid_tree_generation 188479
dev_item.uuid 3ec00099-47c9-4bb3-a0c6-a6a4df8fed06
dev_item.fsid 833d4ef2-375b-4e9e-b2ae-8f0440a74e3e [match]
dev_item.type 0
dev_item.total_bytes 966367641600
dev_item.bytes_used 934187892736
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 18266193920)
length 33554432 owner 2 stripe_len 65536 type SYSTEM|RAID1
io_align 65536 io_width 65536 sector_size 4096
num_stripes 2 sub_stripes 1
stripe 0 devid 1 offset 23644340224
dev_uuid 3ec00099-47c9-4bb3-a0c6-a6a4df8fed06
stripe 1 devid 2 offset 173980778496
dev_uuid 62fad050-53a2-4546-9bec-7ba94b8ca796
item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 8652341641216)
length 33554432 owner 2 stripe_len 65536 type SYSTEM|RAID1
io_align 65536 io_width 65536 sector_size 4096
num_stripes 2 sub_stripes 1
stripe 0 devid 2 offset 2148532224
dev_uuid 62fad050-53a2-4546-9bec-7ba94b8ca796
stripe 1 devid 1 offset 1048576
dev_uuid 3ec00099-47c9-4bb3-a0c6-a6a4df8fed06
backup_roots[4]:
backup 0:
backup_tree_root: 17204510720 gen: 188496 level: 1
backup_chunk_root: 18266193920 gen: 188481 level: 1
backup_extent_root: 17204396032 gen: 188496 level: 2
backup_fs_root: 17204379648 gen: 188470 level: 2
backup_dev_root: 17192943616 gen: 188481 level: 1
backup_csum_root: 8651268734976 gen: 188479 level: 2
backup_total_bytes: 1932735283200
backup_bytes_used: 1859602763776
backup_num_devices: 2
backup 1:
backup_tree_root: 17205215232 gen: 188497 level: 1
backup_chunk_root: 18266193920 gen: 188481 level: 1
backup_extent_root: 17205100544 gen: 188497 level: 2
backup_fs_root: 17205084160 gen: 188470 level: 2
backup_dev_root: 17192943616 gen: 188481 level: 1
backup_csum_root: 8651268734976 gen: 188479 level: 2
backup_total_bytes: 1932735283200
backup_bytes_used: 1859603304448
backup_num_devices: 2
backup 2:
backup_tree_root: 17206214656 gen: 188498 level: 1
backup_chunk_root: 18266193920 gen: 188481 level: 1
backup_extent_root: 17206132736 gen: 188498 level: 2
backup_fs_root: 17206116352 gen: 188470 level: 2
backup_dev_root: 17192943616 gen: 188481 level: 1
backup_csum_root: 8651268734976 gen: 188479 level: 2
backup_total_bytes: 1932735283200
backup_bytes_used: 1859603828736
backup_num_devices: 2
backup 3:
backup_tree_root: 17206902784 gen: 188499 level: 1
backup_chunk_root: 18266193920 gen: 188481 level: 1
backup_extent_root: 17206968320 gen: 188499 level: 2
backup_fs_root: 17206116352 gen: 188470 level: 2
backup_dev_root: 17192943616 gen: 188481 level: 1
backup_csum_root: 8651268734976 gen: 188479 level: 2
backup_total_bytes: 1932735283200
backup_bytes_used: 1859603828736
backup_num_devices: 2
Thank you very much for your support,
yeslow
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-07-01 19:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-01 14:59 Can't mount RAID-0 btrfs volume yeslow
2023-07-01 18:13 ` Roman Mamedov
2023-07-01 19:52 ` yeslow
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.