From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: NFS4 crack Date: Thu, 22 Sep 2005 14:07:36 -0400 Message-ID: <4332F2E8.8030107@redhat.com> References: <1127407973.8365.26.camel@lade.trondhjem.org> <4332EC26.9010307@redhat.com> <1127411552.8365.41.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 mx1.redhat.com ([66.187.233.31]:32226 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1750922AbVIVSIN (ORCPT ); Thu, 22 Sep 2005 14:08:13 -0400 To: Trond Myklebust In-Reply-To: <1127411552.8365.41.camel@lade.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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. The NFS server also has to do its own special checking and sometimes this checking conflicts with the checking done in the normal "from user mode" path. --- Without a great deal of work and many new interfaces, there is no way to get something like the NFS server to run correctly outside of the kernel address space. There are correctness issues such as Trond has pointed out and there are performance issues as well. Is there inherent problem with the NFS server being implemented as an alternate VFS layer in the kernel, with its own requirements? Or is this an academic problem? Unless we are willing to consider moving to a micro-kernel approach, ala Mach, then we are going to need to consider the requirements of kernel based applications in addition to user level applications. Thanx... ps