From owner-svn-src-all@FreeBSD.ORG Wed Apr 15 00:52:05 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32F86106566B; Wed, 15 Apr 2009 00:52:05 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id D40AF8FC15; Wed, 15 Apr 2009 00:52:04 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3F0q3ZY089397; Tue, 14 Apr 2009 17:52:03 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id xf96jbz6xayjxcu9r85gcb2kfw; Tue, 14 Apr 2009 17:52:03 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49E52FB3.9070800@freebsd.org> Date: Tue, 14 Apr 2009 17:52:03 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Robert Watson References: <200904141139.n3EBdudA004806@svn.freebsd.org> <49E4D2BF.2040503@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Edward Tomasz Napierala Subject: Re: svn commit: r191055 - head/lib/libc/string X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 00:52:05 -0000 Robert Watson wrote: > On Tue, 14 Apr 2009, Tim Kientzle wrote: >> A related issue: It would be really nice to be able to find out >> whether a file had extended ACLs or extended attributes based on the >> information returned from stat(2). > > Kirk, Poul-Henning, and I discussed precisely this during the initial > UFS2 design session. The idea was that we'd allocate a system flag that > was essentially a "there are ACL-related extended attributes", I was thinking a bit that indicated the existence of *any* extended metadata, not just ACLs. Userspace consumers can then query EAs, ACLs, etc. if they see this bit set. If we have bits to burn, we could assign separate bits for specific types of extended metadata--such as ACLs--but I think we need to start with something pretty broad. The variety of extended metadata is only going to increase over time. > could be used in-kernel to avoid EA reads, and from userspace to avoid > (or trigger) ACL reads. I still think it would be a good idea to do > this, although we might want to think a bit about failure modes if > there's a crash between EA update and inode update. You could synthesize this bit at stat() time and not store it on disk at all. Alternatively, you could order inode update before EA update to get conservative behavior: If the bit isn't set, that would guarantee that there was no extended metadata. Note that this fits well with having a single bit that indicates "there exists some extended metadata"; clients will have to be prepared to handle the case where the bit is set but the particular metadata of interest to them isn't there after all. My primary concern here is finding ways to avoid extraneous system calls; whether the bit is stored on disk or is synthesized sounds like a filesystem-level optimization that I don't personally much care about. Tim