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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
