Re: [RFC PATCH] Generic name to handle and open by handle syscalls

["Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>]

On Sat, 20 Feb 2010 12:01:38 -0700, Andreas Dilger <adilger@sun.com> wrote:
> On 2010-02-19, at 02:49, Aneesh Kumar K. V wrote:
> > On Fri, 19 Feb 2010 02:34:29 -0700, Andreas Dilger <adilger@sun.com>  
> > wrote:
> >>
> >> What is the expected lifespan of "fh" to remain valid in the kernel?
> >> Presumably this is not just the encoding of the inode number into a
> >> buffer, or it would be too easy to forge from userspace.  That means
> >> there needs to be some unguessable state in the kernel for each file
> >> handle, that may potentially need to be kept indefinitely if there is
> >> no expiry.
> >>
> >> Will "fh" be portable between processes?  I assume that is the  
> >> intent,
> >> but good to declare the actual semantics of the syscalls before they
> >> go into the kernel.
> >
> > Life time rule and uniqueness rule should be same as the NFS file  
> > handle. My understanding is there is no expiry.
> 
> Yes, and NFS file handles can be a pain in the ass, because it means  
> inode numbers/devices/fsid should never be changed for fear of  
> breaking NFS.  I'd much rather advertise that handles have a limited  
> lifespan (e.g. at most until the server reboots, possibly sooner) so  
> that there isn't an expectation of them lasting forever.

That will make the interface not useful for applications like user
space NFS server right ?  Most of them want server to map the handle
to an inode even after a server crash right. The crash recovery might
be done in case of these network file system with the above assumptions.

-aneesh