panic: assertion: leaf->base.delete_tid == 0 in hammer_ip_delete_range
Matthew Dillon
dillon at apollo.backplane.com
Mon Oct 18 00:55:45 PDT 2010
:Hi,
:
:I just got this panic on master. I don't know how to reproduce it.
:Kernel and dump are on leaf, ~mh/crash/*.0
:
:DragonFly v2.7.3.1283.gfa568-DEVELOPMENT #1: Wed Oct 13 12:08:28 CEST
:2010 x86_64
:
:Max
Thanks Max. I think I figured out what happened and I'm glad I had
the assertion there. Basically it asserted because it was trying to
modify an inode snapshot instead of a current inode.
I tracked the problem down to a situation where a snapshot inode is
caught with its nlinks count set to 0. This isn't supposed to be
possible (that is the inode should not be visible in the filesystem
if nlinks is 0), but there are a few places where a raw B-Tree scan can
instantiate an inode where I think it can happen.
When that happens and the vnode is then later discarded by the kernel
there was a piece of code designed to truncate the data if the file
had nlinks == 0 (i.e. no longer visible in the directory hierarchy)
which was not checking to see if the file was a snapshot or not.
I have committed a fix to master which will likely be MFCd to the
release branch before we release.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the Bugs
mailing list