Delete a directory, crash the system

Frank Leonhardt frank2 at
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.

Regards, Frank.

More information about the freebsd-questions mailing list