Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1727426 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: JBD2: Spotted dirty metadata buffer.... Wolfgang Walter <linux@stwm.de> - 2017-09-06 15:00 +0200
    Re: JBD2: Spotted dirty metadata buffer.... Andreas Dilger <adilger@dilger.ca> - 2017-09-06 20:10 +0200

#1727426 — Re: JBD2: Spotted dirty metadata buffer....

Am Montag, 28. November 2016, 12:26:38 schrieb Wolfgang Walter:
> Am Mittwoch, 23. November 2016, 16:40:07 schrieb Andreas Dilger:
> > On Nov 23, 2016, at 3:43 AM, Wolfgang Walter <linux@stwm.de> wrote:
> > > Am Dienstag, 22. November 2016, 16:02:53 schrieben Sie:
> > >> On Nov 22, 2016, at 6:56 AM, Wolfgang Walter <linux@stwm.de> wrote:
> > >>> Am Montag, 21. November 2016, 17:49:36 schrieben Sie:
> > >>>> On Nov 21, 2016, at 8:28 AM, Wolfgang Walter <linux@stwm.de> wrote:
> > >>>>> Hello,
> 
> [snip]
> 
> > 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 

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.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

[toc] | [next] | [standalone]

#1727670

[Multipart message — attachments visible in raw view] — view raw

On Sep 6, 2017, at 6:46 AM, Wolfgang Walter <linux@stwm.de> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web