On Sun, Nov 27, 2011 at 11:24:03PM +0300, Alex wrote: > BTW, after last resume from disk fs was corrupted but fsck managed > to fix this error. So I think severity of this issue should be > raised. Can you reproduce this reliably? What was running at the time of the s2disk? What appears to be going on is that insert_inode_locked() is failing at fs/ext4/ialloc.c:887, probably because there's another inode with that inode number already on the superblock's hash list. The error codepath if insert_inode_locked() fail is incorrect; it's going to fail_drop, which tries dropping the inode's dquot (but we haven't calle ddquot_initialize)inode) yet) and calls unlock_new_inode(), but I_NEW hasn't been set because insert_inode_locked(). So the warning is easy to fix; we just need to have it jump to fail instead of fail_drop. But the bigger issue is why did insert_inode_locked() failed in the first place. Did this error happen *right* after the system resumed, or did some amount of time pass before the warning triggered? This could have happened because the in-memory (or possibly on-disk) copy of the inode allocation bitmap has gotten corrupted, for example. What was the nature of the file system corruption which e2fsck decided that it need to correct? Regards, - Ted -- 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
