Hi Ted,
Unfortunately my laptop died today and I can't retest this issue. I'll
provide more information once and if I repair it.
Thanks,
Alex
On 28.11.2011 00:34, Ted Ts'o wrote:
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
