On Sat, May 13, 2000 at 04:07:04PM -0400, Thomas Bushnell, BSG wrote:
>
> > 2. Storing the location of the directory entry:
> > This is not constant under rename operations, thus it fails to fulfill
> > requirement two.
> > We could reflect this by changing the node cache, but we can't change the
> > filehandle cache_id's in diskfs, so diskfs will disagree with us.
>
> This is not a serious problem. If you choose this implementation, all
> you have to do is purge the cache of the changing id.
I am considering this, however, I am a bit concerned about performance
impact (as the name cache would become effectively unused except if you
lookup a file to which a reference is help and which is still in the cache).
> It is also reasonable to propose simple changes to libdiskfs that make
> things easier.
I was thinking about a callback to be called when the inode number is
"forgotten" by libdiskfs, but this would in the most abstract sense require
a reference count on the inode number, which is probably too heavy.
As an alternative, I am considering overwriting diskfs_purge_lookup_cache
and drop the inode from the cache if there is no living node (as I know that
in this case diskfs will not remember the inode). This will only work as
long as diskfs doesn't change its inodish behaviour, though.
In a broader view, it absolutely makes sense to keep inodes in the cache
until the file is unlinked, as this is what resembles "the inode concept"
best. Just think of a virtual inode table in memory, instead a real inode
table on disk. I am currently tending toward this because it is the "best
fit" and does not depend on clever internal knowledge about diskfs
behaviour.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED] PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
