On Mon, Apr 26, 2010 at 03:42:45PM +0530, Aneesh Kumar K. V wrote: > On Fri, 23 Apr 2010 16:02:14 -0600, Andreas Dilger <adilger@xxxxxxx> wrote: > > On 2010-04-23, at 05:38, Aneesh Kumar K.V wrote: > > > +long do_sys_name_to_handle(const char __user *name, > > > + struct file_handle *fh) > > > +{ > > > + /* > > > + * name to handle conversion only done for regular files > > > + * directories and symbolic links > > > + */ > > > > Out of curiosity, why not do this for other types of files? It makes > > sense from a consistency POV, so that the userspace code doesn't have > > to special-case each file by checking the type first (which would mean > > doing an extra path traversal and stat for each file first, adding > > overhead). > > The limitation directly came from the XFS ioctl. But I don't see a > reason why we should limit it for this syscall. To better support > symlink and regular files i now have did sys_name_to_handle and > sys_lname_to_handle syscalls. I also did a freadlink syscall that will > return the symlink target name from the handle. > > > > > > > I'd always thought it would be cool to have a distributed filesystem where named pipes/sockets work across clients by using the IO transport of the filesystem, making single-system image environments a lot easier to implement. > > > > > + /* we ask for a non connected handle */ > > > + retval = exportfs_encode_fh(path.dentry, (struct fid *)handle, > > > + &handle_size, 0); > > > > Since there is virtually no overhead to do so, why not always return a connected handle? This will allow the kernel to reconnect the looked-up dentries into the tree, instead of creating all disconnected dentries. > > > > open by handle would return a connected dentry for directory. Since we > use a simple acceptable function that accept any dentry alias with > exportfs_decode_fh I was wondering whether we should return a connected > handle ? It would be simply increasing the size of the handle ? Well, and it means the filehandle changes when you rename the file to a different directory. Do you really want that? --b. -- 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