Commit-to-disk policies for {ACLs, capabilities, MAC labels...}, EAs

[Robert Watson]

While doing performance testing on the current FreeBSD EA and ACL
implementations, I've observed a substantial cost overhead in situations
where ACL inheritence is involved -- for example, during sub-directory
creation under a directory that has a default ACL.  In this scenario, it
is necessary to read two ACLs (access, default) for the parent, and write
two ACLs (access, default) for the child.  POSIX.1e doesn't make clear (as
far as I can tell) what guarantees are made by the interfaces with regards
to disk commit.  Right now, my implementation provides a synchronous EA
model: for system EAs, writes are written out synchronously such that
write requests do not return until the EAs are committed to disk.  This is
also true for EA deletion (returning the EA to undefined).  Moving to an
model where guarantees are not made during EA writes removes the
performance overhead--in reality, the reads and writes are small, it's
only the latency on the write that has high cost.

This raises a number of questions: the answers need not be the same across
all platforms, but I'm interested in the opinions of various projects that
have implemented extended attributes previously.  There are several
approaches you could take in assigning consistency properties to EA
operations: they could be the same for all EAs, all EAs in a namespace,
for a particular named EA, or be determined by operation characteristics
(including a flag of some sort).  Many current file systems differentiate
"data" and "meta-data" in offering consistency properties.  EAs might be
awarded meta-data status in journalled or soft-update-enabled file
systems, meaning that they are given strong ACID-like properties (possibly
sans-durable until a later commit).  Or they might be treated as normal
file data, potentially sync'd to disk on a call to fsync().

While there are a number of optimizations that might be made regarding
ACLs over EAs, adding synchronous operation latency to file creation can
substantially impact the performance of many applications -- in
particular, compilation operations.  To get the best security properties,
you'd really like to guarantee that file protection changes have
conservative properties.  You might also, however, want to sync protection
changes to data changes, something that many existing file systems don't
do--perhaps we simply accept that failure cases may be poor and optimize
for performance.  Anyway, opinions would be appreciated.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message