From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicholas Miell Subject: Re: NFS4 crack Date: Thu, 22 Sep 2005 14:48:10 -0700 Message-ID: <1127425690.2865.11.camel@entropy> References: <1127407973.8365.26.camel@lade.trondhjem.org> <4332EC26.9010307@redhat.com> <1127411552.8365.41.camel@lade.trondhjem.org> <4332F2E8.8030107@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Trond Myklebust , Bryan Henderson , Neil Brown , akpm@osdl.org, andros@citi.umich.edu, bfields@citi.umich.edu, Christoph Hellwig , linux-fsdevel@vger.kernel.org, Olaf Kirch Return-path: Received: from rwcrmhc12.comcast.net ([204.127.198.43]:20379 "EHLO rwcrmhc12.comcast.net") by vger.kernel.org with ESMTP id S1751204AbVIVVtB (ORCPT ); Thu, 22 Sep 2005 17:49:01 -0400 To: Peter Staubach In-Reply-To: <4332F2E8.8030107@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-09-22 at 14:07 -0400, Peter Staubach wrote: > Trond Myklebust wrote: > > >to den 22.09.2005 Klokka 13:38 (-0400) skreiv Peter Staubach: > > > > > >>It seems to me that a "system call" could implemented which would allow > >>a file to be "opened" via the file handle. > >> > >> > > > >Sure, but open alone isn't sufficient. A lot (most?) of the operations > >involving filehandles are acting on directories. > > > >Imagine if someone renames a directory on the server while the NFS > >server is in the middle of an unlink() operation, for instance. > > > > Yup, although you could resolve that by introducing a whole set of > operations which work off of file descriptors, instead of pathnames. > Then, inside of the kernel, to do the real operation, the file > descriptor would get turned back into the inode, but without the > pathname look portion. Things like funlink(fd, name), fmkdir(fd, name), > frmdir(fd, name), etc. Other operating systems have implemented at > least a subset of these sorts of calls and it gets ugly quickly. Solaris 10 calls them fchownat(2), fstatat(2), futimesat(2), openat(2), renameat(2), and unlinkat(2). They mostly exist to support their extended attributes implementation (hence the "at" postfix, and not to be confused with Linux's xattrs), but they work for general filesystem usage. Besides being an interface to extended attributes and maybe making an userspace NFSd feasible, they probably also improve filename lookup performance on sufficiently deep directory heirarchies (think of httpd opening /var/www/vservers/www.blah.com/html/ and then resolving everything for that vserver relative to the cached fd). -- Nicholas Miell