jcm@mtunb.ATT.COM (was-John McMillan) (02/24/89)
Earlier flames regarding UNIX(rg) I/O and databases suggested that
UNIX Block-I/O deferred-writes leave databases in unreliable states.
This was because of the unflushed cache contents at the time of
crashes. (At least so far as I could identify amidst the flames.)
An E-mail item from John R. MacMillan [!] raised an interesting
point: in <sys/file.h>, on the 3B1, there's a flag FSYNC.
Examining the sources, and testing, indicates:
NON-deferred (block until written) I/O is available.
Add the following line to
/usr/include/fcntl.h:
#define O_SYNC 020 /* synchronous write option */ /* JCM */
Either OPEN(2) or FCNTL(2) can be used to set this file attribute.
This has been there for some time -- probably as long as there has
been an FSYNC entry in 'file.h'. (As a kernel-repair person, there's
always the problem of living too close to the code to notice the
features!)
It is supported in SVR3, also. (In SVR3, however, there is NO need
to add the 'define'.)
Finally: remember, this is an abusable resource. It consumes
disk-throughput by performing a write-through of the cache for
each write into the cache.
zB.:
for (i=0; i<256; i++) write(fid, bfr , 4);
Using O_SYNC, the above causes a minimum of 256 disk-accesses.
Using the standard deferred I/O, the above require 1 disk-access.
Another example:
for (l=0;l<1000;l++) {lseek(fid,0,0); write(fid, b, 4096);}
Using O_SYNC: Real=118.6s User=.05s Sys=8.7s (6386/135MB)
Real=100.8s User=.03s Sys=1.0s (3B1/67MB)
Otherwise: Real= 2.5s User=.04s Sys=2.4s (6386/135MB)
Real= 1.0s User=.01s Sys= .2s (3B1/67MB)
It's possible the database issues were flared in another newsgroup.
But it's the 3B1 users who may need to add the define -- and I haven't
the foggiest recollection of where it came up ... sigh.
Back under the bridge...
john mcmillan -- att!mtunb!jcm -- muttering for himself, ONLYditto@cbmvax.UUCP (Michael "Ford" Ditto) (02/25/89)
In article <1417@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: > for (l=0;l<1000;l++) {lseek(fid,0,0); write(fid, b, 4096);} > Using O_SYNC: Real=118.6s User=.05s Sys=8.7s (6386/135MB) > Real=100.8s User=.03s Sys=1.0s (3B1/67MB) > Otherwise: Real= 2.5s User=.04s Sys=2.4s (6386/135MB) > Real= 1.0s User=.01s Sys= .2s (3B1/67MB) The SYNC vs. non-SYNC ratio seems about right, but I'm a bit surprised at the 6386 vs. 3B1 ratio. Is the 3B1 really faster? Did the 6386 have a really slow disk? Even so, that wouldn't explain the CPU time. Just wondering. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com