On Sat, 20 Feb 2010 12:01:38 -0700, Andreas Dilger <adilger@xxxxxxx> 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@xxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
