16 Jan
2015
16 Jan
'15
8:14 p.m.
Sixth Edition and 7th Edition are different. Looking at the code, 6th Edition waits on
the updates, but 7th Edition delays the writes(bdwrite()) and then calls bflush() when all
finished. The three sync’s were indeed to give the disk driver time to do all the IO
sitting on the queue. The HP driver used disksort() so those blocks wouldn’t necessarily
be written in the order they were touched.
We used to use one sync and just watch the disk’s activity light.
Brantley
South Suite Software
On Jan 16, 2015, at 8:39 AM, random832(a)fastmail.us wrote:
On Fri, Jan 16, 2015, at 03:40, Tom Ivar Helbekkmo
wrote:
What this means is that the second sync, by
waiting for its own
superblock writes, will wait until all the inode and file data flushes
scheduled by the first one have completed.
Everything I've read indicates that nothing in the sync call actually
waits on anything, and that it's actually just the time taken to type
the second and third command on a 110 baud terminal gives the first one
time to finish executing.
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs