[PVFS-developers] FW: Inode Caching Problem
Rainey Alan - araine
Alan.Rainey@acxiom.com
Thu, 18 Sep 2003 11:12:58 -0500
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.