Date: Sat, 1 Jun 1996 15:59:16 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hdalog@zipnet.net Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: Breaking ffs - speed enhancement? Message-ID: <199606012259.PAA22318@phaeton.artisoft.com> In-Reply-To: <199606011103.HAA09983@hda> from "Peter Dufault" at Jun 1, 96 07:03:28 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > This seems unlikely. O_ASYNC has to do with SIGIO for sockets. Perhaps > > > you mean O_FSYNC. O_FSYNC is a no-op in 4.4Lite and in FreeBSD. Perhaps > > > you mean MNT_ASYNC. MNT_ASYNC is (almost?) a no-op in 4.4Lite but is > > > partly implemented in FreeBSD. > > > > I mean whatever O_SYNC is in System V, which says whether to wait for > > the write request to complete before returning from the write request, > > or whether it's OK to stick the requests onto a queue which is allowed > > to be reordered by write optimization algorithms at their discretion. > > The O_SYNC flag is file based (the fcntl and open flags). There > is no POSIX O_FSYNC - there is O_SYNC for all metadata committed > to disk and O_DSYNC for "only that needed to retrieve the data" > committed to disk. Note that these flags require a synchronous > write for the data, resulting in more I/O instead of less and not > doing what Joe was trying to do. > > Even with _POSIX_SYNCHRONOUS_IO and nothing opened *SYNC (that is, > you can be as aggressive as you are clever), POSIX requires that > the file access times be updated when a "stat" or "fstat" happens > and when no process has the file open. This precludes a standard > way of efficiently handling files that are being rapidly opened > and closed where you don't care about the access times. I think > they should have changed this part of the spec when they defined > the sychronous I/O to let you only update the access fields when > the associated I/O takes place, permitting standard "aggressively > asynchronous" behavior. The kernel implementation has little or nothing to do with POSIX, which can just as easily be implemented in a library (as OS/2, NT, and VMS have proven). I am talking about the flag to the block I/O subsystem that causes the kernel operation that actually reads/writes disk blocks to require synchronous completion before allowing the continued usage of state as if it were idempotent. The name in SVR3 and SVR4 for this parameter flag was OSYNC, *NOT* O_SYNC. I typo'ed when I first wrote it. Please quit addressing this as if it were anything other than a kernel space issue. Thanks, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606012259.PAA22318>