[PVFS-developers] FW: Inode Caching Problem

[Rob Ross]

I think that the best thing to do from a practical standpoint is implement 
your patch and leave this better approach alone.  It would indeed mean 
significant changes.

Thanks,

Rob

On Thu, 18 Sep 2003, Rainey Alan - araine wrote:

> The dentry only contains the *filename*.  So for example, with the file
> /foo/bar/zee, the file->f_dentry->d_iname (and d_name struct) would only
> contain "zee", while the pvfs_inop(file->f_dentry->d_inode)->name would be
> something like "192.168.1.5:3000/foo/bar/zee".  Each dentry *does* have a
> pointer to its parent, so I suppose that walking back up that list could get
> you the full path name, and if there is a way to tack on the ip:port
> somewhere in pvfsd, then that would *eliminate* any possible caching
> problems dealing with the pvfs_inop(inode)->name.
> 
> Maybe you could also do away with storing the
> pvfs_inop(file->f_dentry->d_inode)->handle, since that number should always
> be in file->f_dentry->d_inode->i_ino?
> 
> This would *dramatically* change the pvfsd code though, right?  It seems to
> depend on that pvfs_inode struct.  Maybe that struct could just be
> dynamically built per-request instead of stored in the inode (which gets
> cached in the kernel)?  That could potentially be slow...
> 
> Again, my lack of experience with this code makes me hesitant to try
> implementing such a major change... :)
> 
> Alan
> 
> > Alan,
> > 
> > I think that this is the best solution to this (somewhat awkward) problem.
> 
> > The added compare shouldn't cost us much, and your testing (thanks for 
> > that by the way) seems to back that up.  Anything is better than 
> > additional messaging :)!
> > 
> > This does beg an interesting question however; if we have a good way to 
> > rebuild the filename from the dcache, maybe we shouldn't keep the file 
> > name in the inode at all?
> > 
> > Rob
> 
> 
> 
> 
> 
> 
> **********************************************************************
> The information contained in this communication is
> confidential, is intended only for the use of the recipient
> named above, and may be legally privileged.
> If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, 
> distribution, or copying of this communication is strictly
> prohibited.
> If you have received this communication in error,
> please re-send this communication to the sender and
> delete the original message or any copy of it from your
> computer system. Thank You.
> 
>