From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Subject: Re: [RFC] POSIX ACL kernel infrastructure Date: Fri, 9 Aug 2002 15:17:54 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <200208091517.54983.agruen@suse.de> References: <200208041546.35234.agruen@suse.de> <200208091422.49879.agruen@suse.de> <20020809133246.B9622@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Nathan Scott , Linux-FSDevel , Olaf Kirch , Chris Mason , Jeff Mahoney Return-path: To: Christoph Hellwig In-Reply-To: <20020809133246.B9622@infradead.org> List-Id: linux-fsdevel.vger.kernel.org On Friday 09 August 2002 14:32, Christoph Hellwig wrote: > On Fri, Aug 09, 2002 at 02:22:49PM +0200, Andreas Gruenbacher wrote: > > I read this as `Why are you not returning the permissions nfsd should see > > in struct, which the inode->getattr IOP fills?'. Please correct me if > > this is not what you wanted to say. > > I meant adding an acl field to struct kstat that is supposed to be filled > by ->getattr. I see. That's problematic on most filesystems, because retrieving the ACL from disk is pretty expensive, and often is not needed. For things like stat() it is not needed, for example. > > The usual callers of getattr should see the unmasked permissions; it's > > only nfsd that needs this special treatment, and only on filesystems that > > have ACLs enabled. The getattr IOP is used by others as well. > > So why is the a new IOP better in that respect? Only nfsd needs to pay the runtime cost. > > If you had adding an extra field to struct kstat in mind, this just seems > > too intrusive to me for solving the nfsd problem. The problem will go > > away in the future when all NFSv3 clients are using the ACCESS RPC, > > anyway. It's just a hack right now. > > So you want to add two inode operations for a hack that is only needed to > support old NFS clients? It will be needed for NFSv2 and NFSv3, until all NFSv3 clients support the ACCESS RPC properly. The ACCESS RPC patch for the client side in the current kernel still has some performance issues. The hack won't go away anytime soon, but a lot fewer people will be affected by the underlying problem in a year or so. I also think the inode operations are a good thing to keep independent of the nfsd issue. > Do you have any profiling data that shows major overhead when going through the xattr layer? No, this would be tricky to measure. The interface requires copying around ACLs, and endianness conversions on big endian machines; it's simply inappropriate for that task. --Andreas. ------------------------------------------------------------------ Andreas Gruenbacher SuSE Linux AG mailto:agruen@suse.de Deutschherrnstr. 15-19 http://www.suse.de/ D-90429 Nuernberg, Germany