Date: Mon, 2 Apr 2001 21:09:54 -0700 (PDT) From: Robert Watson <rwatson@FreeBSD.org> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/ufs/ufs ufs_extattr.c Message-ID: <200104030409.f3349sw76029@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
rwatson 2001/04/02 21:09:54 PDT
Modified files:
sys/ufs/ufs ufs_extattr.c
Log:
o Change the default from using IO_SYNC on EA set and delete operations
to not using IO_SYNC. Expose a sysctl (debug.ufs_extattr_sync) for
enabling the use of IO_SYNC.
- Use of IO_SYNC substantially degrades ACL performance when a
default ACL is set on a directory, as there are four synchronous
writes initiated to define both supporting EAs for new
sub-directories, and to set the data; two for new files. Later, this
may be optimized to two writes for sub-directories, one for new
files.
- IO_SYNC does not substantially improve consistency properties due
to the poor consistency properties of existing permissions (which
ACLs are a superset of), due to interaction with soft updates,
and due to differences in handling consistency for data and file
system meta-data.
- In macro-benchmarks, this reduces the overhead of setting default
ACLs down to the same overhead as enabling ACLs on a file system
and not using them. Enabling ACLs still introduces a small
overhead (I measure 7% on a -j 2 buildworld with pre-allocated
EA backing store, but this is not rigorous testing, nor in any way
optimized).
- The sysctl will probably change to another administration method
(or at least, a better name) in the near future, but consistency
properties of EAs are still being worked out. The toggle is defined
right now to allow easier performance analysis and exploration
of possible guarantees.
Obtained from: TrustedBSD Project
Revision Changes Path
1.29 +24 -10 src/sys/ufs/ufs/ufs_extattr.c
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104030409.f3349sw76029>