fhget and ftpfs

[Csaba Henk]

On Sat, Jul 09, 2005 at 01:02:15PM +0100, Robert Watson wrote:
> 
> On Sat, 9 Jul 2005, Csaba Henk wrote:
> 
> >But there are two functions which behave nastily: nnpfs_fhget and 
> >nnpfs_fhopen in nnpfs.c (after renaming functions and files). Eg., 
> >nnpfs_fhget looked like this:
> 
> On FreeBSD, HAVE_GETFH and HAVE_GETFHOPEN should be defined for any recent 
> version, so arlad's fcache code will use them in preference to pioctl(), 
> rather than the custom fh*() pioctl's.  You're probably aware of this 
> already, but te function of getfh() is to return a unique identifier for a 
> file that persists for the lifetime of the file and can be used to access 
> the file without iterating through the path.  fhopen() then takes that 
> identifier (handle) and opens the file using the handle.  In this manner, 
> Arla can access files in the cache without paying the cost of path lookup, 
> as well as use the handle as a common identifier with the kernel to say 
> "yes, this is the file from the cache I want you to expose at point <x> in 
> the nnpfs namespace".

Yes, I guessed that's the functionality of these calls.

> As an FYI, file handles were originally intended to be persistent across 
> reboots, as their current incarnation is derived from the implementation 
> of NFS on most platforms, as NFS handles are used to identify files 
> between clients and servers.  However, on many modern systems, the 
> identifiers do not always persist across reboot, as they are ofen derived 
> from the device number on which the file system holding the file is 
> mounted, meaning that if the storage devices are rearranged, SCSI IDs 
> change, etc, the device numbers associated with the file system will 
> change, invalidating the handle.  So you should try to avoid relying on 
> the persistence of file handles across reboots or remounts of the file 
> system holding the cache.  As none of the nnpfs-based file systems I know 
> of expose file hadles on the wire, this is probably not a problem as long 
> as any cache files are re-mapped to file handles from real paths when the 
> daemon starts up, and are only referred to by file handle after that 
> mapping has occurred.

Interesting...

> >Any alternative solution for the fhget/fhopen stuff, or idea about 
> >getting the kerberos thing right?
> 
> #ifdef KERBEROS seems an odd ifdef in the Arla code for whether or not to 
> use pioctl(), but that's the view of someone who hasn't looked at the Arla 
> code in several years. :-)

Ok I see. In fact, I decided on to rely on the kerberos implementation
because I had problems with the native one. Maybe I should have been more
desperate to get that approach working...

Thanks for the detailed and insightful help.

Cheers, Csaba