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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 27, 2010 at 11:43:44AM +0530, Aneesh Kumar K. V wrote:
> On Mon, 26 Apr 2010 13:57:52 -0400, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
> > 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?
> > 
> 
> Atleast the usecase i am looking to we should retain the same handle
> even after rename. So i guess getting a non connected handle is the
> right thing

I think so.  And if somebody really had to have the other behavior, I
think it could probably be implented in userspace.

--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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux