From owner-freebsd-hackers Sat Jun 1 04:02:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA17609 for hackers-outgoing; Sat, 1 Jun 1996 04:02:48 -0700 (PDT) Received: from hda (ip57-max1-fitch.zipnet.net [199.232.245.57]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA17592 for ; Sat, 1 Jun 1996 04:02:43 -0700 (PDT) Received: (from dufault@localhost) by hda (8.6.11/8.6.9) id HAA09983; Sat, 1 Jun 1996 07:03:29 -0400 From: Peter Dufault Message-Id: <199606011103.HAA09983@hda> Subject: Re: Breaking ffs - speed enhancement? To: terry@lambert.org (Terry Lambert) Date: Sat, 1 Jun 1996 07:03:28 -0400 (EDT) Cc: hackers@freebsd.org In-Reply-To: <199606010123.SAA19324@phaeton.artisoft.com> from "Terry Lambert" at May 31, 96 06:23:59 pm Reply-to: hdalog@zipnet.net X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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. -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267