[rescue] Looking for I/O performance metrics

[Greg A. Woods]

[ On Monday, November 26, 2001 at 13:20:26 (-0600), Derrick D. Daugherty wrote: ]
> Subject: Re: [rescue] Looking for I/O performance metrics
>
> does `sync` take a while to return?  Sounds like the interfaces aren't
> happy

If you're talking about any modern "real" Unix (eg. SunOS-5, or even
*BSD), the time it takes for "sync" to return is irrelevant.  If I'm not
mistaken this statement has been in every sync(2) manual page since V6:

  BUGS
     sync() may return before the buffers are completely flushed.

Most implementations of sync(8) normally should return immediately since
they just call sync() and exit.

The reason of course is that sync(2) just schedules an immediate write
of dirty buffers and they're not actually pushed out until the devices
they're going off to are ready to handle the I/Os.

IIRC on SCO Xenix sync(8) didn't return until all bufferes were flushed,
but not many other systems fix the above "bug" since it's very hard to
fix given the way the disk drivers usually work.

BTW, if anyone remembers being told to type "sync<CR>" three times
before halting the machine (which unfortunately many clue-less tech
writers translated into the incorrect "sync; sync; sync<CR>") the reason
for this was that by the time you got your third prompt back (especially
on a real teletype printing terminal) the buffers would all really have
been written out and the disks would be quiescent.

Note too that most implementations of the update(8) daemon are just:

	while (1) {
		sync();
		sleep(30);
	}

At some point in NetBSD's history the update daemon was replaced by a
kernel thread (ioflush) that effectively does much the same thing.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>