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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

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