Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cti1!mpledger From: mpledger@cti1.UUCP (Mark Pledger) Newsgroups: comp.unix.internals Subject: Re: What does sync() _really_ do? Message-ID: <341@cti1.UUCP> Date: 17 Dec 90 12:15:50 GMT References: Organization: Comprehensive Technologies Int., Arlington VA Lines: 57 steinar@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: > - > - sync(); sync(); sync(); > - > >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@cti.com --------------------------------------------------------------------------