btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096

btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096

[marcos k.]

Hallo to all of you,
and sorry for asking the very specialists directly, 
but I found no useful answer to my problem.

my btrfs-filesystem is corrupt and can not be mounted==>
btrfsprogs v5.1 and btrfsprogs v4.15.1
# btrfs check /dev/dm-2
ERROR: tree block bytenr 0 is not aligned to sectorsize 4096

BUT btrfsprogs v4.4 can at least check the filesystem and I have (limited)
access to it. Still can not mount ...

I would appreciate it very much, if someone could give me a hint,
marcos k.

======= output ============= output =============
lap13:~ # uname -a 
Linux ernnb113 5.1.5-1-default #1 SMP Mon May 27 07:14:33 UTC 2019 (6ad4f79) x86_64 x86_64 x86_64 GNU/Linux

lap13:~ # btrfs --version 
btrfs-progs v5.1 

lap13:~ # btrfs fi show 
Label: 'rootfs'  uuid: 0fe9bec5-fd4e-4a4b-a855-b0412d9916a4
        Total devices 1 FS bytes used 134.48GiB
        devid    1 size 310.13GiB used 143.06GiB path /dev/mapper/linuxvg-rootlv

Label: 'homefs'  uuid: d3659317-3d28-42f0-beb3-2480fb2b0900
        Total devices 1 FS bytes used 406.77GiB
        devid    1 size 590.00GiB used 577.00GiB path /dev/mapper/linuxvg-homelv

lap13:~ # btrfs fi df /dev/dm-2 
ERROR: not a btrfs filesystem: /dev/dm-2

lap13:~ # dmesg | grep -i btrfs
[    7.485437] Btrfs loaded, crc32c=crc32c-intel, assert=on
[    7.487711] BTRFS: device label rootfs devid 1 transid 3190209 /dev/dm-1
[    7.616145] BTRFS info (device dm-1): disk space caching is enabled
[    7.616148] BTRFS info (device dm-1): has skinny extents
[    7.662371] BTRFS info (device dm-1): enabling ssd optimizations
[    8.263761] BTRFS info (device dm-1): turning on discard
[    8.263763] BTRFS info (device dm-1): disk space caching is enabled
[    8.998829] BTRFS info (device dm-1): device fsid 0fe9bec5-fd4e-4a4b-a855-b0412d9916a4 devid 1 moved old:/dev/mapper/linuxvg-rootlv new:/dev/dm-1
[    8.999507] BTRFS info (device dm-1): device fsid 0fe9bec5-fd4e-4a4b-a855-b0412d9916a4 devid 1 moved old:/dev/dm-1 new:/dev/mapper/linuxvg-rootlv
[   10.484594] BTRFS: device label homefs devid 1 transid 2087298 /dev/dm-2
[   10.520725] BTRFS info (device dm-2): turning on discard
[   10.520728] BTRFS info (device dm-2): disk space caching is enabled
[   10.520730] BTRFS info (device dm-2): has skinny extents
[   10.522139] BTRFS critical (device dm-2): corrupt node: root=3 block=16384 slot=0, invalid NULL node pointer
[   10.523238] BTRFS error (device dm-2): failed to read chunk root
[   10.545271] BTRFS error (device dm-2): open_ctree failed

lap13:~ # btrfs check /dev/dm-2
ERROR: tree block bytenr 0 is not aligned to sectorsize 4096
Couldn't read chunk tree
ERROR: cannot open file system
Opening filesystem to check...

lap13:~ # btrfs rescue super-recover /dev/dm-2
All supers are valid, no need to recover

lap13 :~ # btrfs rescue chunk-recovery /dev/dm-2
Scanning: DONE in dev0
Check chunks successfully with no orphans
Chunk tree recovered successfully

lap13:~ # btrfs check /dev/dm-2
ERROR: tree block bytenr 0 is not aligned to sectorsize 4096
Couldn't read chunk tree
ERROR: cannot open file system
Opening filesystem to check...

Re: btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 3971 bytes --]



On 2019/6/7 下午6:40, marcos k. wrote:
> Hallo to all of you,
> and sorry for asking the very specialists directly, 
> but I found no useful answer to my problem.
> 
> my btrfs-filesystem is corrupt and can not be mounted==>
> btrfsprogs v5.1 and btrfsprogs v4.15.1
> # btrfs check /dev/dm-2
> ERROR: tree block bytenr 0 is not aligned to sectorsize 4096

Although the error message is not good for human to read, the tree block
bytenr 0 means some tree block is definitely corrupted.

> 
> BUT btrfsprogs v4.4 can at least check the filesystem and I have (limited)
> access to it. Still can not mount ...
> 
> I would appreciate it very much, if someone could give me a hint,
> marcos k.
> 
> ======= output ============= output =============
> lap13:~ # uname -a 
> Linux ernnb113 5.1.5-1-default #1 SMP Mon May 27 07:14:33 UTC 2019 (6ad4f79) x86_64 x86_64 x86_64 GNU/Linux
> 
> lap13:~ # btrfs --version 
> btrfs-progs v5.1 
> 
> lap13:~ # btrfs fi show 
> Label: 'rootfs'  uuid: 0fe9bec5-fd4e-4a4b-a855-b0412d9916a4
>         Total devices 1 FS bytes used 134.48GiB
>         devid    1 size 310.13GiB used 143.06GiB path /dev/mapper/linuxvg-rootlv
> 
> Label: 'homefs'  uuid: d3659317-3d28-42f0-beb3-2480fb2b0900
>         Total devices 1 FS bytes used 406.77GiB
>         devid    1 size 590.00GiB used 577.00GiB path /dev/mapper/linuxvg-homelv
> 
> lap13:~ # btrfs fi df /dev/dm-2 
> ERROR: not a btrfs filesystem: /dev/dm-2
> 
> lap13:~ # dmesg | grep -i btrfs
> [    7.485437] Btrfs loaded, crc32c=crc32c-intel, assert=on
> [    7.487711] BTRFS: device label rootfs devid 1 transid 3190209 /dev/dm-1
> [    7.616145] BTRFS info (device dm-1): disk space caching is enabled
> [    7.616148] BTRFS info (device dm-1): has skinny extents
> [    7.662371] BTRFS info (device dm-1): enabling ssd optimizations
> [    8.263761] BTRFS info (device dm-1): turning on discard
> [    8.263763] BTRFS info (device dm-1): disk space caching is enabled
> [    8.998829] BTRFS info (device dm-1): device fsid 0fe9bec5-fd4e-4a4b-a855-b0412d9916a4 devid 1 moved old:/dev/mapper/linuxvg-rootlv new:/dev/dm-1
> [    8.999507] BTRFS info (device dm-1): device fsid 0fe9bec5-fd4e-4a4b-a855-b0412d9916a4 devid 1 moved old:/dev/dm-1 new:/dev/mapper/linuxvg-rootlv
> [   10.484594] BTRFS: device label homefs devid 1 transid 2087298 /dev/dm-2
> [   10.520725] BTRFS info (device dm-2): turning on discard
> [   10.520728] BTRFS info (device dm-2): disk space caching is enabled
> [   10.520730] BTRFS info (device dm-2): has skinny extents
> [   10.522139] BTRFS critical (device dm-2): corrupt node: root=3 block=16384 slot=0, invalid NULL node pointer

Kernel tree checker also detects such problem.
Your chunk tree is corrupted, with one node slot pointing to bytenr 0.

Normally we shouldn't have a system chunk at logical bytenr 0, but it's
also possible that all those existing check is too strict.

Would you please provide the following info?

# btrfs ins dump-super -fa /dev/dm-2

If there is no system chunk at bytenr 0, then it must be some strange
thing happened in your fs.

Thanks,
Qu

> [   10.523238] BTRFS error (device dm-2): failed to read chunk root
> [   10.545271] BTRFS error (device dm-2): open_ctree failed
> 
> lap13:~ # btrfs check /dev/dm-2
> ERROR: tree block bytenr 0 is not aligned to sectorsize 4096
> Couldn't read chunk tree
> ERROR: cannot open file system
> Opening filesystem to check...
> 
> lap13:~ # btrfs rescue super-recover /dev/dm-2
> All supers are valid, no need to recover
> 
> lap13 :~ # btrfs rescue chunk-recovery /dev/dm-2
> Scanning: DONE in dev0
> Check chunks successfully with no orphans
> Chunk tree recovered successfully
> 
> lap13:~ # btrfs check /dev/dm-2
> ERROR: tree block bytenr 0 is not aligned to sectorsize 4096
> Couldn't read chunk tree
> ERROR: cannot open file system
> Opening filesystem to check...
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 3416 bytes --]



On 2019/6/12 下午10:12, marcos k. wrote:
> Hallo again,
> 
>  
> 
> On Wednesday, 12 June 2019 15.47.49 CEST you wrote:
> 
>> > The patch helped me a lot !!! ;-)) After compiling a new btrfs
> 
>> > kernel-module with your small patch, the filesystem just mounted! After
> 
>> > a "scub" and "balance" of the btrfs filesystem, it could be mounted with
> 
>> > the regular btrfs kernel-module. So far so good ...
> 
>> >
> 
>> > After another full backup (rsync) of the home-directory I checked the
> 
>> > filesystem again. The btrfs check indicated a lot of errors.
> 
>>
> 
>> Would you mind to share the output?
> 
>>
> 
> Strange enough I found a "check --repair" output of the corrupted
> homefs. But the filesystem does not exist any more. I will attach the
> output.

So indeed some corruption.
Some corruption in extent tree and some in fs tree.

I'd say the corruption is pretty serious, not some simple one.
But surprisingly, the btrfs-progs --repair doesn't make things worse.
Either you're using the latest btrfs-progs or you're lucky.
(older btrfs-progs could easily further corrupt the fs if btrfs check
aborted).

> 
>  
> 
> The png-files are cached icons from "~/.cache/thumbnails"
> . It seems that most of the errors are cached data.

To me, it looks like a failed metadata CoW.

Would you mind to share about the layout of dm-2?

Recently we have some reports of failed data/metadata CoW on device
mapper devices.
Not sure if dm is contributing to the problem.

> 
>>
> 
>> If scrub shows no error but check reports, then there is something wrong
> 
>> in metadata, but not some serious corruption to prevent btrfs to read
> 
>> the tree blocks.
> 
>>
> 
>> > I tried to
> 
>> > remove all files and all directories (except the subvolume dirs) but
> 
>> > cloudn't. I tried to check --repair, check --init-csum-tree
> 
>> > , check --init-extent-tree the remainig files but without success.
> 
>>
> 
>> --init-csum/extent-tree normally makes no sense, except some special case.
> 
>> And if --repair doesn't help, we need the original output to determine
> 
>> what's wrong.
> 
>>
> 
> Yes I read about normaly not using --init-csum/extent-tree. Therefor I
> did "check --repair" on the remaining files and dirs, then tried to
> remove them, then did another "check --repair" on the remaining files,
> tried to remove them .... So only after a lot of tries with "check
> --repair" I did a last test with "--init-csum/extent-tree" and another
> "check --repair", which did not help. Some dirs e.g. in
> /home/user/.cache could not be removed.

I remember --repair should have the ability to repair mismatch in
INODE_ITEM/DIR_ITEM/DIR_INDEX.

I may need to double check the repair code for that part.

Thanks,
Qu

> 
>>
> 
>> Thanks,
> 
>> Qu
> 
>>
> 
>> > I had to make a new btrfs over the old one. After copying all the data
> 
>> > back, everything is good now.
> 
>> >
> 
>> >  
> 
>> >
> 
>> > Maybe a switch would be helpful to mount "old"-btrfses. Some user might
> 
>> > not be able to patch and compile kernel-mudules. At least everybody
> 
>> > should be informed to balance his "old" btrfs.
> 
>> >
> 
>> >  
> 
>> >
> 
>> > Thanks a lot, marcos. k.
> 
>> >
> 
>> >  
> 
>> >
> 
>> >  
> 
>> >
> 
>> >  
> 
>  
> 
>  
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]