Date: Tue, 14 Apr 2009 17:52:03 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Edward Tomasz Napierala <trasz@freebsd.org> Subject: Re: svn commit: r191055 - head/lib/libc/string Message-ID: <49E52FB3.9070800@freebsd.org> In-Reply-To: <alpine.BSF.2.00.0904142016240.19879@fledge.watson.org> References: <200904141139.n3EBdudA004806@svn.freebsd.org> <49E4D2BF.2040503@freebsd.org> <alpine.BSF.2.00.0904142016240.19879@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E52FB3.9070800>