[OpenAFS-devel] understanding afs_remunlink() and why .__afsXXX don't get cleaned up

[chas williams - CONTRACTOR]

In message <x3ac12gnsb.fsf@nowhere.com>,Adam Megacz writes:
>In afs_vnop_remove.c:afs_remove() I'm having a bit of trouble
>understanding the difference between "adp" and "tvc" (and where on
>earth the "ndp" identifier comes from).

adp usually refers to the parent (or diretory) vcache pointer.  tvc
usually refers to the vcache pointer for the object in question.

the ndp stuff is #ifdef AFS_OSF_ENV and doesnt apply anymore.
afs has dropped osf support as i recall.

>What seems to be happening is that the CUnlinked bit gets set on tvc
>but not adp.  This appears to be intentional.  However,
>afs_InactiveVCache() never seems to get invoked on that tvc, though it
>does get invoked on adp.  Hacking afs_remove() to set the bit on adp
>causes afs_remove() to get much farther along, apparently up until
>avc->mvid==0 is checked.

afs_remove() takes a directory and a name to remove from the directory.
i dont think you would want to set cunlinked on the directory (its not
being removed). 

>Any hints?

as i recall, afs_remove() should just go ahead and remove the named
entry from the directory if the entry doesnt have any references.
if the entry is still referenced (typically being help open by another
process) the entry is just flagged cunlinked (and renamed to .__afsXXXX).
eventually the process holding this vache entry busy will exit.  when
that happens VOP(inactive) is called and the file should get removed
by afs_inactivevcache().

fstrace can be fairly useful in following this activity.

there are some cases that dont remove .__afsXXXX entries.  like the
client crashes while holding one of these files open.

a simple test case to demostrate your problem can make it easier for
another developer to track this down.