linux26-vcache-reclaim-cleanup-20050119
authorChas Williams <chas@cmf.nrl.navy.mil>
Wed, 19 Jan 2005 22:46:06 +0000 (22:46 +0000)
committerDerrick Brashear <shadow@dementia.org>
Wed, 19 Jan 2005 22:46:06 +0000 (22:46 +0000)
commit73437ee7d469765df30285369301e3907fee0a3c
tree6b20c8c61d4bb608ed06ee9c2f67be2b6b18d220
parent8ccd2d91d89fc3ed0170a458853ec95ff274c87d
linux26-vcache-reclaim-cleanup-20050119

"ok, if you ever drop
dcache_lock you need to go to restart (i think that's pretty clear).
shrink_dcache_parent() _might_ reduce a dentry count to 0.  in the
previous version, it seemed to make the assumption that this would
always happen.  if shrink_dcache_parent() is unsuccessful and the
dentry is a directory, we cant restart.  we would just find the
the dentry again and do the same thing over (we could always d_drop
but you shouldnt do this to active directories -- see d_invalidate).

if we find a busy dentry, we abort all processing for this inode.
going back to restart would find the same busy inode.  (i suppose
we could use a d_flag to keep track of which dentry has been shrunk.
this has other trouble, like who resets the flag and when?)  since we
only do this for directories and d_alias typically only grows due to
soft/hard links (as far as i can tell) this scheme seems reasonable."
src/afs/afs_vcache.c