public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: "marcos k." <Marcos.Ka@posteo.net>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs progs v5.1: tree block bytenr 0 is not aligned to sectorsize 4096
Date: Fri, 7 Jun 2019 19:57:14 +0800	[thread overview]
Message-ID: <bef76760-2376-d6c4-4808-ac4e9d7bd361@gmx.com> (raw)
In-Reply-To: <3057842.IWvHFmXsFP@ernsv0>


[-- 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 --]

  reply	other threads:[~2019-06-07 11:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
     [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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bef76760-2376-d6c4-4808-ac4e9d7bd361@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=Marcos.Ka@posteo.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox