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: Mon, 26 Apr 2010 15:42:45 +0530 Message-ID: <877hnuplnm.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 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: Andreas Dilger Return-path: Received: from e28smtp09.in.ibm.com ([122.248.162.9]:60273 "EHLO e28smtp09.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396Ab0DZKMt (ORCPT ); Mon, 26 Apr 2010 06:12:49 -0400 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by e28smtp09.in.ibm.com (8.14.3/8.13.1) with ESMTP id o3Q9Km37008224 for ; Mon, 26 Apr 2010 14:50:48 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3QACkql3543128 for ; Mon, 26 Apr 2010 15:42:46 +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 o3QACj9G028352 for ; Mon, 26 Apr 2010 20:12:46 +1000 In-Reply-To: <6EE769C5-7307-49FF-BA8B-8C19EF04373E@sun.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 ? -aneesh