Re: JBD2: Spotted dirty metadata buffer....

[Andreas Dilger]

On Sep 6, 2017, at 6:46 AM, Wolfgang Walter <linux@xxxxxxx> wrote:
> 
> Am Montag, 28. November 2016, 12:26:38 schrieb Wolfgang Walter:
>> Am Mittwoch, 23. November 2016, 16:40:07 schrieb Andreas Dilger:
>>> Stepping back a bit - does this problem only happen with an external
>>> journal device, or does it also happen with an internal journal?
>> 
>> So I tried that this weekend. I got again these messages
>> 
>> JBD2: Spotted dirty metadata buffer (dev = dm-22, blocknr = 241763277). There's a risk of filesystem corruption in case of system crash.
>> 
>> So this also happens with an internal journal.
>> 
> 
> [snip]
> 
> I last tried with 4.9.46 and I still see that problem when rsyncing data to the filesystem: errors similar to
> 
> JBD2: Spotted dirty metadata buffer (dev = dm-25, blocknr = 1008028301). There's a risk of filesystem corruption in case of system crash.
> 
> A later filesystem check does not show any errors.
> 
> 
> With 4.9.46 stable kernels I also sometimes get the following error:
> 
> EXT4-fs error (device dm-25): ext4_iget:4501: inode #74061557: comm rsync: checksum invalid
> or
> EXT4-fs error (device dm-25): ext4_iget:4501: inode #155844677: comm nfsd: checksum invalid
> 
> A filesystem check then says that the inode itselfs seems ok but the checksum is indeed wrong.
> 
> As these inodes are inodes of very small files.
> 
> So I finally copied all away and reinitialized the filesystem. But this time without -O inline_data
> 
> Since then all works fine. So I assume there is a proplem with inodes and inline-data (at least until 4.9.46), maybe only with data=journal.

Add Tao Ma, since he is the original inline data author, and it appears that Taobao
is using this feature so are probably interested in fixing any corruption.

Wolfgang, it would be useful if you could figure out what type of block the reported
blocknr=1008028301 is.  You can use "debugfs -c -R 'icheck 1008028301' /dev/dm-25".
I'd suspect, given that this is an inline data problem, that this is an inode table
block, but it is good to be sure.  It would also be useful to see if this inode
number correlates to one of the inodes that have bad checksums.

Cheers, Andreas

Attachment: signature.asc
Description: Message signed with OpenPGP