From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: NFS4 crack\ Date: Mon, 26 Sep 2005 13:13:53 -0400 Message-ID: <43382C51.6000608@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Al Viro , akpm@osdl.org, andros@citi.umich.edu, bfields@citi.umich.edu, Christoph Hellwig , linux-fsdevel@vger.kernel.org, Neil Brown , Olaf Kirch , Trond Myklebust Return-path: Received: from mx1.redhat.com ([66.187.233.31]:32170 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S932394AbVIZROn (ORCPT ); Mon, 26 Sep 2005 13:14:43 -0400 To: Bryan Henderson In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Bryan Henderson wrote: > >Well, I wouldn't want to. I can't think of anything that an NFS server >does to a directory that couldn't be done cleanly with a single system >call, much the way the POSIX system calls do. > I might object to the characterization of "cleanly". We would need system calls which matched the specific semantics of NFS operations. For example, we would need system calls which understood pre-operations and post-operation attributes. We would need system calls which understood 32 bit limits so that we could correctly implement NFS version 2. NFS version 3 and NFS version 2 are probably close enough that we could use a common set of system calls with appropriate flags, but it does not seem likely that these system calls would suffice for NFS version 4. We could end up with a whole lot of system calls, even if they all went through a common entry point into the kernel. Thanx... ps