> I'm taking a guess here - the effective link count when it came to > removing the parent directory was only two and it should have been three > or more. This gets sanity checked this before proceeding, and panics if > it is not. Why an effective link count of three? We're talking about the > parent of the directory you're trying to zap, right? There's the link to > the directory from its parent, and the '.' link and the ".." link from > the directory you're trying to remove. There may be more if it contains > other directories, but there can't be less. > > Anyway - if you only had a link count of just two effective links at the > start of the delete process it suggests that the link count was messed > up - either a link never existed or its count was wrong. Should the > kernel panic? Well it's a situation that can never happen - it could > simply remove the directory and pretend everything was okay but guess > it was decided it was likely to be a symptom of impending disaster. > Other anomalies return an error. > > In over ten years with FreeBSD systems I can't say I've ever seen this > "cannot happen" situation arise. I'd guess you had an interrupted (by > power failure) inode operation at some time which caused the corruption. > removing a directory is a PITA as it can lead to a race - a context swap > could create a file it it mid-way through the process. > > Regards, Frank.
Interesting. Thanks for the analysis. I'm not a systems guy (Java, mostly), so I don't really have the context to make much sense of kgdb output. What you're saying though makes sense and sounds about right -- it's a laptop and I've inadvertently run the battery down to nothing a few times in the past. All the same, it was a very strange experience. I would not have expected a kernel panic from a simple rm -rf! _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
