https://bugzilla.kernel.org/show_bug.cgi?id=16312 Jan Kara <jack@xxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |axboe@xxxxxxxxx, | |jack@xxxxxxx --- Comment #3 from Jan Kara <jack@xxxxxxx> 2010-07-23 15:30:50 --- I was looking into this. A trivial reproducer is: mknod devzero c 1 5; touch devzero Essentially, the problem is that any device inode can get dirty because of time stamp update or similar reason but some BDIs (in this case the one backing /dev/zero) do not expect dirty inodes. Hmm, I now have to think how to fix this... It would be more natural if device inodes were queued for metadata updates in the queues of "parent" filesystem. But this brings problem that device inode would need to be in two queues - one for metadata update to the parent filesystem and one for data writeout to the device (this is not exactly the case of /dev/zero but if you have a device node for /dev/sdb on /dev/sda, then this is exactly what we would need). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
