http://bugzilla.kernel.org/show_bug.cgi?id=6180
------- Additional Comments From nathans@xxxxxxx 2006-03-15 22:14 -------
Well, will you look at that?
| I'm taking a
| stab in the dark that you may have a corrupt inode nlink field ondisk
| for a particular inode, but thats just a guess at this stage based on
| the oops.
Spot on - so, thats why you're getting a panic anyway, somehow one of
those inodes with nlink==0 is visible through the directory hierarchy
and someone is accessing it; someone else takes it away at the same
time, and boom.
The real root of the problem though is how did the nlink field get that
way... this would probably have happened at some point well before your
panic, so we've got no real clues to go on unfortunately. :(
Hohum, so, I'm back at trying to get you to narrow down what you do to
reproduce it... but I've got no good ideas on how you might do that.
Only other data points here - we can say this is quite unlikely to be
a recent regression (lotsa people seem to be asking..), since I can't
think of anything thats changed recently in XFS that would affect the
inode link count (within XFS anyway, perhaps some VFS change is making
it more likely to occur, but...). Noone else seems to be hitting this
though, which makes me wonder if theres something a bit unusual about
your workload / filesystem accesses thats tickling this ... anything
you can think of?
Oh, and the "error following ag 10 unlinked list" repair message is an
odd one too, I need to go think about what might cause that a bit, cos
it will explain some of your unlinked inodes.
I'd be interested in seeing if it happens again now its repaired, and
if so, whether it happens after a crash or unclean shutdown (i.e. no
unmount), and if so, whether that same xfs_repair message gets dumped.
cheers.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|