Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!amdcad!sun!slovax!lm
From: lm@slovax.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: Workstation Disk I/O
Message-ID: <143502@sun.Eng.Sun.COM>
Date: 9 Oct 90 01:15:16 GMT
References: <14900016@hpdmd48.boi.hp.com> <2387@van-bc.wimsey.bc.ca>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 53

In article <2387@van-bc.wimsey.bc.ca> jtc@van-bc.wimsey.bc.ca (J.T. Conklin) writes:
>In article <14900016@hpdmd48.boi.hp.com> sritacco@hpdmd48.boi.hp.com (Steve Ritacco) writes:
>>Let's consider the SPARCstations, DECstations, Personal Iris, Mips Magnum,
>>NeXT, HP s300/s400, Sony NEWS, etc.
>>
>>How do each of these systems handle their disk I/O, what are the cost/
>>performance advantages of the approaches, what is the realized performance,
>>what is the potential performance, and what is the bottle-neck?
>
>The June 1990 ACM Computer Architecture News contains the article
>"IOStone: A Synthetic File System Benchmark" by Park, Becker, and
>Lipton.  They report the results of their benchmark on a diskfull and
>a diskless Sparcstation, a Sun 3/80, a Decstation 3100, a NeXT, a Sun
>2/120, a Vaxstation II, an Apollo DN3000, and a Macintosh II.
>
>The thing I found interesting was Sun's variable size disk cashe
>really skewed the results of the benchmark.  The diskless Sparcstation
>outpreformed the Vaxstation, the Apollo, and the Mac.

I can answer the original question since I've been active in FS performance
at Sun.  Before I do that I want to comment on the referenced "benchmark".

IOstone is misnamed and misleading.  It ought to be called "cachestone" or
"buffer cachestone".  It does *not* measure I/O performance.  It measures
cache performance.  It *assumes* a buffer cache model and gives misleading
information in the face of unified memory systems such as Multics, Mach, 
and SunOS.  This is a poor benchmark.  Understand my position:  I work for
Sun,  I'm interested in performance,  I want Sun to look good,  this benchmark
makes Sun look good,  and I am saying this benchmark is junk.  I say this
because it gives people the wrong impression.  I would be very happy with
a benchmark that showed off Sun's VM system;  I'm unhappy with a benchmark 
that shows off Sun's VM system and claims to be measuring the I/O system.

OK, that said, what's going on at Sun wrt to FS performance?  Well, good news
and bad news.  The good news is that if you move big files around on UFS you
will be very happy with the next release of SunOS.  I sort of added extents
without adding extents :-)  Basically, we now do 56KB chunks of I/O where before
we would have done 8KB chunks of I/O.  But, big but, Idid not change the on
disk format at all (well, not quite;  the format is the same but the tuning
parameters are different; files are laid out contiguously).

Anyway, there's a paper coming to the winter Usenix, read that for details.

The bad news is that this doesn't help small I/O performance at all.  Still
the same old slow story there, and we haven't got a fix yet.  We're actively
looking at things like Ousterhout's logfs.

In the meantime, tmpfs is much faster in the next release, there was a bug,
with the bug fix kernel builds go 20% faster.  I work in tmpfs almost
exclusively for just this reason (I wrote a little daemon that migrates my 
files to safe storage).
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com