lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <FB4C6A4A-2A9F-4AE2-9CA2-E2C1F881A651@dilger.ca>
Date:   Mon, 21 Nov 2016 17:49:36 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Wolfgang Walter <linux@...m.de>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: JBD2: Spotted dirty metadata buffer....

On Nov 21, 2016, at 8:28 AM, Wolfgang Walter <linux@...m.de> wrote:
> 
> Hello,
> 
> I'm testing EXT4 with an external journal (data=journal). When writing I rather often get
> 
> 	JBD2: Spotted dirty metadata buffer (dev = dm-22, blocknr = 1008028301). There's a risk of filesystem corruption in case of system crash.

Can you please determine what file this block belongs to and/or what kind
of metadata block it is.  You can check "dumpe2fs /dev/dm-22" to list all
of the metadata blocks, and if it isn't listed as filesystem metadata, you
can run "debugfs -c -R 'icheck 1008028301' /dev/dm-22" to find which file
this block belongs to, then "debugfs -c -R 'ncheck <inum>' /dev/dm-22" after
you have the inode number.

> No other message is logged. If I unmount the filesystem an do an forced fsck, all seems fine.

This is likely a bug in the code, marking a block dirty without setting
up the journaling for it correctly.  A few bugs like this were fixed a
while ago by Eric, but those fixes should be in 4.8.8.

> The filesystem as it's journal are on a LV (which is again backed by DRBD). The journal, too.
> 
> I'm using stable kernel 4.8.8.
> 
> I created the journal with:
> 
> 	mkfs.ext4 -O journal_dev -v -b 4096  -L jdyn /dev/export/jdyn
> 
> I created the filesystem with:
> 
> 	mkfs.ext4 -J device=UUID=625d871f-c278-4acb-916d-774dc78dbd8a -v -b 4096 -E stride=$((512/4)),stripe_width=$((512/4*3)),lazy_itable_init=0,nodiscard -O inline_data,mmp -L dyn /dev/export/dyn

It may be that inline_data is the culprit, since this is a relatively new
feature that isn't widely used yet.

Cheers, Andreas

> I tested it also with data=writeback. I didn't see these errors then.
> 
> Regards,
> --
> Wolfgang Walter
> Studentenwerk München
> Anstalt des öffentlichen Rechts
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ