fhget and ftpfs

[Robert Watson]

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".

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.

On FreeBSD, the SYS_pioctl system call number is reserved for nnpfs's use, 
so if you need to us the nnpfs-provided system call implementations, 
that's the system call number to pass into syscall().

I'm sure there's either an excellent or a historical reason for the 
pioctl() paths to be #ifdef KERBEROS, but since I haven't really read or 
used the Arla code in several years, I don't know what that is (other than 
the hint that it should be KAFS in the comment).

> This function may get many things wrong (struct member inconsistency?), 
> but at least, it compiles. I've also seen that in the beginning I'll 
> need a k_hasafs() call, so I insterted that into the code, too. Now it 
> compiled.

A casual read suggests you're returning whatever random stack garbage was 
in 'ret' at the time to the caller, since you're not explicitly setting it 
to 0.  The callers of the various fh*() interfaces likely check for 
negative or non-zero return values, and then assume errno will contain a 
valid error.  So whatever is left in errno from the last error will be 
what the consumer sees, and that could well be EINTR.  However, I think 
you can basically make the cache management functions wrappers around the 
native fhget() and fhopen() system calls, which is what Arla does if they 
are present.

> 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. :-)

Robert N M Watson