Re: AW: AW: Tree-checker Issue / Corrupt FS after upgrade ?

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

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



On 2020/8/17 上午8:56, benjamin.haendel@gmx.net wrote:
> Hi Qu,
> 
> attached are both dumps, the Chunk dump is rather large (8 MB-ish)so i zipped it.

Unfortunately, the lowmem mode is correct.

The extent 30077723082752 belongs to csum tree, but it is inside a data
chunk.
This looks like a bug, again, caused by older kernels.

This is a case where we can't recover by btrfs-check.

Thankfully, that problem can disappear if those involved tree blocks get
COWed (aka, defrag the whole fs), and they shouldn't cause any problem
nor prevent latest kernel to mount/read them.


For your current inode generation problem, they can be fixed without the
help of btrfs-check, but you still need to mount the fs with older kernel.

In your kernel log, locate the offending inodes by:
> [118342.511680] BTRFS critical (device dm-0): corrupt leaf:
root=5 block=22798248325120 slot=0 ino=747373811, invalid inode
generation: has 18446744073709551492 expect [0, 207862]

That ino=747373811 shows the inode number, root=5 shows the fs tree.

Then you only need to use the following command to copy that inode (of
course, use the older kernel which doesn't has such check):

# find <mnt> -inum 747373811
Which will locate the offending files, then you can just copy the files
to replace the original, or just remove them.

You need to execute this several times until all offending ones are removed.

From your previous reply, the offending inodes are:
ino=746324257
ino=746324416
ino=746324557
ino=746324792
ino=746325907
ino=746455361
ino=746455691
ino=746458110
ino=746586563
ino=746587192
ino=746717976
ino=747372936
ino=747372980
ino=747373811
ino=747506165
ino=747506282


BTW, from your extent tree dump, your fs is really old, so old that a
lot of new optimizations are not enabled, and tons of older kernel bugs
are bothering your fs and causing problems.

I totally understand that migrating so many data is not an easy thing,
but I strongly recommend you to migrate the contents to a newly created
btrfs (and only mounted by kernel newer than v5.4)

Thanks,
Qu

> 
> Best Regards,
> Ben
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Qu Wenruo <quwenruo.btrfs@gmx.com> 
> Gesendet: Montag, 17. August 2020 01:16
> An: benjamin.haendel@gmx.net
> Betreff: Re: AW: Tree-checker Issue / Corrupt FS after upgrade ?
> 
> 
> 
> On 2020/8/16 下午5:50, benjamin.haendel@gmx.net wrote:
>> Hi Qu,
>>
>> attached the log that i ran with the piped ">" Output first (not as 
>> much as i expected as i can not copy paste unlimited data sadly) and below the errors (there were many more) that i manually pasted as an example.
> 
> It looks like the bad extent flags (possible a false alert) is masking the inode generation error.
> 
> Thus it makes lowmem failed to repair.
> 
> Would you please provide the following dump? (can be provided with mounted fs)
> 
> # btrfs ins dump-tree -t extent <device> | grep -A 10 300781367296
> 
> # btrfs ins dump-tree -t chunk <device>
> 
> Thanks,
> Qu 
> 


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