What does sync() _really_ do?

Mark Pledger mpledger at cti1.UUCP
Mon Dec 17 23:15:50 AEST 1990


steinar at ifi.uio.no (Steinar Kj{rnsr|d) writes:


>The above subject and imposed question may seem trivial, but I have so far
>failed to find the answer (I browsed through the 4.3 book by McKusick, Karels
>and Quarterman, references to pertinent pages here are welcome). The question
>arised when a disk vendor presented results from a benchmark which purpose
>was to measure read/write transfer rates for his drive. His scenario
>was this:

> - a stand alone BSD (SunOS 4.0.3 I think) box in single user mode
> - no other disk activity in the system

>The test program looked something like this:

> - <write a HUUUUGE file and measure the write transfer rate>
> - sync(); sync(); sync();
> - <read the same file back again and measure the read transfer rate>
> 
>Both read and write of the file use normal IO (asynchronous) operations which
>therefore involves the buffer cache. The disk vendor's assumption is that
>the three sync() calls will guarantee that the read pass of the test will
>read data  off the media, not from the buffer cache, while I say that
>although the sync() calls force dirty pages in the buffer cache to be written
>to the disk, you have no guarantee that those pages also will be wiped out
>from the cache. I find this especially true since there are no other
>disk activity in the system at the time when the test is running. What would
>be the purpose of really clearing the cache when you have nothing to replace
>the cleared pages with?

>Who are right?


If memory serves me right, sync() does not CLEAR the file buffers, but
only writes all dirty buffers to disk and clears the dirty bit flag in
the file buffer header structure.  Your right that there is no guarantee
the dirty buffers will be wiped out.  In fact, considering your system
is idle other than your processes, I would tend to believe the file 
buffers are still available for use.  Therefore in the vendor's test case,
by updating all file buffers, he quarantees that the reads will come from
the file buffers and not the actual disk.  A subtle improvement indeed!




-- 
Sincerely,


Mark Pledger

--------------------------------------------------------------------------
CTI                              |              (703) 685-5434 [voice]
2121 Crystal Drive               |              (703) 685-7022 [fax]
Suite 103                        |              
Arlington, VA  22202             |              mpledger at cti.com
--------------------------------------------------------------------------



More information about the Comp.unix.internals mailing list