On Nov 21, 2016, at 8:28 AM, Wolfgang Walter [off-list ref] 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Cheers, Andreas