Weekly Edition
Return to the Kernel page
| |||||||||||||
Open by handle
Most Linux users never deal directly with file handles; indeed, most may
not even know they exist. Of the rest, the bulk will have an experience
limited to the cheery "stale file handle" message seen by NFS users at
horribly inopportune times. In fact, a file handle is just a means by
which a file can be uniquely identified within a filesystem. Handles are
used in NFS, for example, to represent an open file in a way which allows
the server to be almost entirely stateless. Handles are not normally used
by, or even available to user-space applications.
Aneesh Kumar is trying to change that situation with a short patch series adding two new system calls:
int name_to_handle(const char *name, struct file_handle *handle);
int open_by_handle(struct file_handle *handle, int flags);
The first takes the given name and looks up the associated file handle, which is returned in the handle structure. That handle can then be passed to open_by_handle() to get an open file descriptor for the file. Only privileged users can call open_by_handle(); otherwise it could be possible for a malicious local user to bypass the normal permission checks on the directories in the path to a specific file. Why would an application developer want to open a file in two steps instead of just calling open()? It comes down to the ability to write filesystem servers that run in user space. Such a server could use name_to_handle() to generate handles for files on the underlying filesystem; those handles are then passed to the filesystem's clients. At some future time, the client can pass the handle back to actually open the file. This type of feature is also already used with the XFS filesystem for backup and restore operations and with a hierarchical storage management system. Discussion of these system calls has been minimal, thus far. It does seem that some work will be needed still to better describe what a file handle really is, and, in particular, what its expected lifetime will be. Without some clarity in that area, it will be hard to write applications which can make proper use of file handles. (Log in to post comments)
Open by handle Posted Feb 25, 2010 11:36 UTC (Thu) by nix (subscriber, #2304) [Link]
Why is this reminding me of the seekdir()/telldir() horror?
I suppose that the handle being an opaque structure adds enough freedom that filesystems won't be locked into a seekdir()-style nightmare... if need be you could simply wrap the filename into a structure and return that :)
Open by handle Posted Feb 25, 2010 17:27 UTC (Thu) by kvaneesh (subscriber, #45646) [Link]
That will not work with rename.
Open by handle Posted Feb 25, 2010 17:36 UTC (Thu) by nix (subscriber, #2304) [Link]
True.
It'll work even less well with unlink(). In fact, if we don't have a close_handle(), this gives rise to exactly the same resource usage and when-can-we-recycle-handles problems that telldir() has got. Whatever goes into a handle, it essentially has to be correlated with the inode number, and thus physically present on and persistent in the FS, and won't work well with FAT. Unsurprisingly these are the same constraints imposed by NFS
I hope open_by_handle() is allowed to return -ESTALE...
Open by handle Posted Feb 25, 2010 17:47 UTC (Thu) by kvaneesh (subscriber, #45646) [Link]
It does return -ESTALE if it can't find a mapping inode.
Open by handle Posted Feb 25, 2010 20:50 UTC (Thu) by nix (subscriber, #2304) [Link]
I should have just checked the code rather than wasting your time like
that. Apologies.
Open by handle Posted Mar 9, 2010 13:07 UTC (Tue) by philippe.deniel (guest, #64210) [Link]
This would be a great benefit to have a way to address files by filehandles and not only through the "old fashioned" POSIX way that uses names. I am working on a NFS Server Running in User Space (see http://nfs-ganesha.sourceforge.net) and this kind of features would be pretty helpful to my work.
|
|||||||||||||