From: Wolfgang Walter <linux@stwm.de>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: JBD2: Spotted dirty metadata buffer....
Date: Wed, 06 Sep 2017 14:46:48 +0200 [thread overview]
Message-ID: <14919146.PgSzFZYKi6@stwm.de> (raw)
In-Reply-To: <10283498.RxsF1TCk0q@stwm.de>
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
next prev parent reply other threads:[~2017-09-06 12:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-21 15:28 JBD2: Spotted dirty metadata buffer Wolfgang Walter
2016-11-22 0:49 ` Andreas Dilger
2016-11-22 13:56 ` Wolfgang Walter
2016-11-22 23:02 ` Andreas Dilger
[not found] ` <11848279.gFnWiZMlh7@stwm.de>
[not found] ` <6EBBE85C-8A87-4D8B-9897-3D67D4B6D732@dilger.ca>
2016-11-28 11:26 ` Wolfgang Walter
2017-09-06 12:46 ` Wolfgang Walter [this message]
2017-09-06 18:07 ` Andreas Dilger
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=14919146.PgSzFZYKi6@stwm.de \
--to=linux@stwm.de \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.