* btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096
@ 2019-06-07 10:40 marcos k.
2019-06-07 11:57 ` Qu Wenruo
[not found] ` <2675522.6BlBp3bEyT@ernnb113>
0 siblings, 2 replies; 3+ messages in thread
From: marcos k. @ 2019-06-07 10:40 UTC (permalink / raw)
To: linux-btrfs
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...
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096
2019-06-07 10:40 btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096 marcos k.
@ 2019-06-07 11:57 ` Qu Wenruo
[not found] ` <2675522.6BlBp3bEyT@ernnb113>
1 sibling, 0 replies; 3+ messages in thread
From: Qu Wenruo @ 2019-06-07 11:57 UTC (permalink / raw)
To: marcos k., linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096
[not found] ` <33202605.PZYGi36h5c@ernnb113>
@ 2019-06-12 14:22 ` Qu Wenruo
0 siblings, 0 replies; 3+ messages in thread
From: Qu Wenruo @ 2019-06-12 14:22 UTC (permalink / raw)
To: marcos k., linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-06-12 14:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-07 10:40 btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096 marcos k.
2019-06-07 11:57 ` Qu Wenruo
[not found] ` <2675522.6BlBp3bEyT@ernnb113>
[not found] ` <1acbfdec-0e7e-7be7-3612-7dea01db4df2@gmx.com>
[not found] ` <33202605.PZYGi36h5c@ernnb113>
2019-06-12 14:22 ` Qu Wenruo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).