Delete a directory, crash the system
frank2 at fjl.co.uk
Sat Jul 27 15:02:14 UTC 2013
On 27/07/2013 13:58, David Noel wrote:
>> Post the stack trace of the core and maybe someone can help you.
> panic: ufs_dirrem: Bad link count 2 on parent
> cpuid = 0
> KDB: stack backtrace:
> #0 0xffffffff808680fe at kdb_backtrace+0x5e
> #1 0xffffffff80832cb7 at panic+0x187
> #2 0xffffffff80a700e3 at ufs_rmdir+0x1c3
> #3 0xffffffff80b7d484 at VOP_RMDIR_APV+0x34
> #4 0xffffffff808ca32a at kern_rmdirat+0x21a
> #5 0xffffffff80b17cf0 at amd64_syscall+0x450
> #6 0xffffffff80b03427 at Xfast_syscall+0xf7
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.
More information about the freebsd-questions