Bug 39732 - JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 2512725). There's a risk of filesystem corruption in case of system crash.
Summary: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 2512725). There's a...
Status: RESOLVED OBSOLETE
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: fs_ext4@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 36912
  Show dependency tree
 
Reported: 2011-07-22 04:22 UTC by Witold Baryluk
Modified: 2016-04-19 02:43 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.0.0-rc7
Tree: Mainline
Regression: Yes


Attachments

Description Witold Baryluk 2011-07-22 04:22:54 UTC
I was just updating some packages in 32-bit Debian unstable, under highload on my Thinkpad T43 (uniprocessor pentium-m). And spoted this thing in log:

[79324.133130] JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 2512725). There's a risk of filesystem corruption in case of system crash.

dm-2 is block device (on LVM on luksCrypt) with /usr on ext4, with journal=data.

I never ever seen such thing.

# cat /proc/mounts  | grep -v fuse
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=1031676k,nr_inodes=220204,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=207032k,mode=755 0 0
/dev/mapper/sredniczarny-root / ext4 rw,relatime,user_xattr,acl,barrier=1,nodelalloc,data=journal 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,size=5120k,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=414060k 0 0
/dev/sda1 /boot ext3 rw,relatime,errors=continue,commit=5,barrier=1,data=ordered 0 0
/dev/mapper/sredniczarny-tmp /tmp ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/mapper/sredniczarny-usr /usr ext4 rw,relatime,user_xattr,acl,barrier=1,nodelalloc,data=journal 0 0
/dev/mapper/sredniczarny-var /var ext4 rw,relatime,user_xattr,acl,barrier=1,nodelalloc,data=journal 0 0
/dev/mapper/sredniczarny-home /home ext4 rw,relatime,user_xattr,acl,barrier=1,nodelalloc,data=journal 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
sctank2 /sctank2 fuse rw,relatime,user_id=0,group_id=0,allow_other 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
/home/baryluk/.Private /home/baryluk/Private ecryptfs rw,relatime,ecryptfs_fnek_sig=caxxxxxx,ecryptfs_sig=e47xxxxx,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
/dev/sr0 /media/cdrom0 iso9660 ro,nosuid,nodev,noexec,relatime 0 0
#


Kenrel config attached.

I found two separate bug in Red Hat bugzilla which are similar, and occurs when usrquota is used, and some quota releated configuration is changed. I have hovewer no quota here (it is just laptop) enabled, configured, or even supported by my custom kernel.

Any ideas?


exact kernel version 3.0.0-rc7-t43-prod-00159-ge6625fa-dirty

(dirty only because -march=pentium-m added to the build). gcc 4.6.1-4 used. 32bit i386.
Comment 1 Witold Baryluk 2011-07-25 03:51:59 UTC
May it be because of bugs in dcache in rc7? If so, then it should not be issue in 3.0. I also do not seen this again in later rc7, and 3.0 or after that. It was single event.

But it may by also some rare event I accidentally triggered. No data was lost, as I safely rebooted system without problem.
Comment 2 Florian Mickler 2012-01-24 23:17:10 UTC
Is this still a problem in v3.2 / v3.3-rc1 ?

Note You need to log in before you can comment on or make changes to this bug.