Re: [PATCH -V4 2/6] vfs: Add name to file handle conversion support

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

On Fri, 23 Apr 2010 16:02:14 -0600, Andreas Dilger <adilger@sun.com> 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 ?

-aneesh