From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: SCSI Performance (Yet Again) Date: Mon, 23 Aug 1993 16:12:32 GMT
In article <1993Aug22.200138.15349@hip-hop.suvl.ca.us> root@hip-hop.suvl.ca.us (Remco Treffkorn) writes:
>Now let's assume the fsync does not happen. That is probably the case
>for most people usinf iozone. But let us also assume the file is larger
fsync() wasn't in the kernel until fairly recently... if it's there now. I
don't know if it is or not, though patches have ben floating around for
several months. (eventually sunsite will quit dropping the connection on me
and I'll finish ftp'ing a current system...)
>The numbers I have seen here suggest that people do not have iozone
>flushing the cache to disk before starting to read. Thus the WRITE
>performance is measured too high! If that is so, then the write
>performance is very disappointing.
Can't speak to this.
>There are some critical assumtions here:
> The file written is larger than the cache. If not you get *very*
> god performance readings. Well, I guess we do not have to worry
> about that.
> You should do an fsync after writing and include the time till
> fsync returns. If you don't then the read performance is too high
> and write performance too high. BUT between the two you will see
> a glimmer of reality.
Another critical assumption is that the cache is flushed all at once. If it
does it a block at a time to free up space for the next buffered write, (e.g.
one physical write per buffered write), performance will suffer because of
buffer management overhead as well as because of the physical write time.
I haven't looked to see what Linux is doing, but since I'm (as I said above)
on an outdated kernel (0.99pl9; the buffer code got rewritten in 0.99pl10 and
later) it wouldn't prove much anyway until I finish upgrading.
++Brandon
-- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca