[OpenAFS-devel] using system inodes on linux

[chas williams - CONTRACTOR]

In message <FEE5413DC1A69C7CC10E50CD@sphinx.andrew.cmu.edu>,Chaskiel M Grundman writes:
>> any other thoughts on the general patch itself?
>I was initially confused by the removal of all the vcache2inode's, but I=20
>eventually found the afs_getattr's and saw the implications.

that was supposed to be a seperate patch (bug #19433) but everything
mashed together in my local tree.  

>I was also concerned about the fact that this (as well as the=20
>getnewvnode-based stuff on XBSD) throws away stat information on files that =
>aren't open/held/whatever. Oh. You dealt with that by keeping one refcount=20
>around that belongs to afs_NewVCache, so that is not a problem either.

actually i borrowed that idea from the OSF code (it makes sense, the
list is a reference).  not holding this extra reference is possibly one
of the reasons that for races in the current code.  afs vcache entries
seem to make their refcounts go 0->1->0 at times.  when 1->0 is done 
with iput() this slips the inodes onto the unused (or whatever) list.  
afs then rushes to get the inodes back off that list.

>> bits bother me but seem to work.  if i handled the afs_remunlink()
>> in .dentry_iput i might not even need afs_InactiveVCache().
>Why do you not want to call InactiveVcache?

i call InactiveVCache when the refcount is going from 2->1.  its possible
that the last refcount isnt from the VLRU reference so the inactive is
too soon.  i cant see how this would happen but afs always surprises me.