On Sat, 3 Mar 2007, Alexander Leidinger wrote:
In FreeBSD we have 3 types, not 2. We have "sync", "noasync" (default) and "async".
Are you sure? 2 independent flags give 4 states. I think the flags are not completely independent, but sync doesn't cancel async in all cases (partly because of layering violations in ffs_update()) so sync together with async gives sync data with an undocumented combination of sync and async metadata.
For async the complete IO is done asynchronous (the meta-data too).
Exccept possibly for (small) bugs.
And for sync the complete IO is synchronous.
Except certainly for (larger) bugs. ffs_inode() normally refuses to do sync writes unless !DOINGASYNC(vp). When DOINGASYNC(vp), it mostly ignores its waitfor arg (this is its layering violation) and does a delayed write (not an async write, but an async write after a delay). This breaks cases where its caller wants to force a non-async write. Callers want to do this in the following cases: - sync together with async on the mount. sync should have precedence. I think the sync code knows to set waitfor = 1 for the call, but doesn't know that ffs_inode() will ignore the setting. - async on the mount with explicit fsync(2) or O_[F]SYNC. fsync(2) sets waitfor = 1, so the inode should get synced even if DOINGASYNC(vp), but it doesn't due to the layering violation. fsync(2) doesn't know how to sync all the directories above the file, and their metadata. O_[F]SYNC for the file together with async for the mount should work for the file like sync together with async for the mount work for all files, but has much the same bugs as fsync(2).
mount(8) tells this with some more words.
It has related bugs. It literally says that sync and async have precedence over each other, but this is impossible. Bruce _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
