http://bugzilla.kernel.org/show_bug.cgi?id=14354 --- Comment #131 from Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 2009-10-27 20:00:51 --- Some more testing of this issue: - if I do something like [root@inspiron-laptop linux]# sync [root@inspiron-laptop linux]# echo b > /proc/sysrq-trigger I never seem to see any problems. I've done the above several times - I started using it as my shutdown replacement, and I'm bisecting another independent issue on the same laptop. And no problems so far. - but when I did the whole power-button thing even when the system looked otherwise idle (it was hung at shutdown, and I waited ten+ seconds), I get in trouble very easily. This makes me suspect that the background flush by bdflush simply isn't working well for ext4. Even when you'd expect things to be idle, and bdflush should hopefully get your metadata out, it just doesn't. I'd suspect the 'wait=0' case in ext4_write_inode. It does the same 'don't do anything' that ext3 does, but presumably the delayed allocation makes for much worse trouble. Notice how just returning zero from ext4_write_inode() will make the general fs/fs-writeback.c just remove the inode from the dirty lists entirely. One thing to note is that the ext4_write_inode() behavior certainly isn't new, but it's entirely possible that the per-bdi writeback logic has changed timing of the writebacks a lot. Which may explain why it's apparently getting more attention in the 2.6.32-rc series, although some people seem to have seen it earlier too. -- Configure bugmail: http://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
