From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K. V" Subject: Re: [PATCH -V4 2/6] vfs: Add name to file handle conversion support Date: Tue, 27 Apr 2010 11:43:44 +0530 Message-ID: <87vdbd4e3r.fsf@linux.vnet.ibm.com> References: <1272022715-11716-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1272022715-11716-3-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <6EE769C5-7307-49FF-BA8B-8C19EF04373E@sun.com> <877hnuplnm.fsf@linux.vnet.ibm.com> <20100426175752.GB12661@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andreas Dilger , hch@infradead.org, viro@zeniv.linux.org.uk, corbet@lwn.net, serue@us.ibm.com, linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com To: "J. Bruce Fields" Return-path: Received: from e28smtp03.in.ibm.com ([122.248.162.3]:54147 "EHLO e28smtp03.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849Ab0D0GNw (ORCPT ); Tue, 27 Apr 2010 02:13:52 -0400 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by e28smtp03.in.ibm.com (8.14.3/8.13.1) with ESMTP id o3R6Dnjr012352 for ; Tue, 27 Apr 2010 11:43:49 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3R6Dnkx3596388 for ; Tue, 27 Apr 2010 11:43:49 +0530 Received: from d28av05.in.ibm.com (loopback [127.0.0.1]) by d28av05.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3R6Dmm3019622 for ; Tue, 27 Apr 2010 16:13:49 +1000 In-Reply-To: <20100426175752.GB12661@fieldses.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 26 Apr 2010 13:57:52 -0400, "J. Bruce Fields" 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 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 -aneesh