NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/benchmar/1707

Internet Message Format | 1992-11-16 | 6.7 KB

Xref: sparky comp.benchmarks:1707 comp.arch.storage:780
Path: sparky!uunet!cbmvax!jesup
From: [e-mail] (Randell Jesup)
Newsgroups: comp.benchmarks,comp.arch.storage
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Message-ID: <[e-mail]>
Date: 17 Nov 92 01:21:08 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 112

[e-mail] (John Bass) writes:
>>    You need to separate multi-tasking from multi-user.  Single-user
>>machines (and this includes most desktop Unix boxes) don't have the activity
>>levels for the example you gave to have any relevance.  It's rare that more
>>than one or two files are being accessed in any given second or even minute.
>
>I would have agreed with you up until last year ... X windows and MS windows
>have drasticly changed the volume of disk I/O on PC's. At the same time,
>disk I/O has become a major wait factor in the startup and initialization
>of most GUI applications ... often contributing 80% of the minute or two
>big applications take to startup. In addition, applications seldom deal with
>simple ascii files .... they are now full of font and layout info, if
>not bitmaps. The evolution was most noticable on my mac ... when I
>first got my 128k mac I didn't understand why all the app's were
>so big ... today I don't think there are may app's that will even
>load on it ... many require more than the 1mb of a Mac Plus.

    Taking minutes to start an application is obscene to begin with (and of
course X is usually horridly bloated).  Even in the cases you site, how much
of the time is X actually reading more than one file at a time?  Sure, it may
be reading 27 different files to start XSuperMarioBase, but I suspect it's
reading them from the single process, one at a time...  The example you gave
was of _massive_ io for a very _small_ portion of a disk.

>Applications that delivered acceptable performance on a 60KB/sec filesystem
>10 years ago, now need 500KB/Sec or more. MSDOS and UNIX V7 filesystems
>don't deliver this type of performance ... single block filesystems
>are a thing of the past.

    So the MSDOS FS is crappy and V7 is ancient.  Is this news?  This
doesn't mean you have to have super-dumb drives and super-intelligent
filesystems to solve the problems.  How does HPFS do?  (Are the HPFS specs
published or on the net somewhere?  I'd like to look into it...)

>>recognition of the costs and complexity involved should be there also.
>>Filesystems are complex beasts, and that complexity can lead to high
>>maintenance costs.  Things that increase the complexity of an already
>>complex item for performance gains that are only rarely needed for the
>>application are suspect.  Also, adding something to an already complex
>>object can be more costly than adding it to a simple object, because the
>>complexities interact.
>
>My point EXACTLY ... SCSI Firmware & Drivers have become too complex,
>in many cases, more complex than the application & filesystem using it!
>Enter IDE, simple firmware and simple drivers. And with some minor
>issues resolved (like better host adapters), better performance.

    My side of it would be that filesystems are too complex already, and
that moving such things to the drive avoids having all the complexity in one
spot.

>>    Why should the single-user have to run everything through a cache?
>>I think direct-DMA works very nicely for a single-user environment, especially
>>if you don't own stock in RAM vendors (as the current maintainers of Unix,
>>OS/2, and WindowsNT seem to).  Reserve the buffers for things that are likely
>>to be requested again or soon - most sequential reads of files are not re-used.
>
>Generally user applications don't ask for a whole file, properly aligned
>and of an even sector length ... the filesystem can. Disk caches don't need
>to use an excessively large amount of DRAM to make significant performance
>increases.

    That depends.  Most stdio's ask for BUFSIZE bytes, which is usually
a multiple of the sector size, and usually on a BUFSIZE boundary.  Most
programs that use low-level reads tend to read into allocated space, which is
usually aligned.  Even if not initially aligned, after reading the first
partial block often all but the last partial block can be read directly.
It also depends what you consider "large".  I tend to consider 50K of buffers
for a FS large (AmigaFS defaults are usually 15K).

>Actually, from my experience, most files opened and read sequentially,
>will be opened and read sequentially again ... and soon. C compilers
>open the sources once, then typically open 6-20 include files which
>will be used again, if not for another compile, by the same users
>next try of the same program. Ditto for the many default, startup
>and font files in a X/motif environment. Make files, shell scripts
>and other such tools are another good example. Many small programs
>are also frequently re-used, especially those used by make & shell
>scripts. In development environments, common libraries are also
>often read.

    There is a small percentage of files that are often re-read.  The
environment matters a lot also: for example, developers may re-read includes
often, while users may start applications every few minutes or hours, which
are read (including startup files) once.

    The problem is of course identifying the files that are likely to be
re-read.  This can be a tough problem, especially if you're not willing to
write to the disk on most file opens for read (to keep info on reuse).

>Caching all writes is also highly productive ... editor writes out
>C source, to be read by C compiler which writes object module read
>by linker which writes the executable to read by system loader when
>the user tests. The cycle repeats, deleting ALL files created by the
>cycle .... if you hold the I/O long enough ... it really isn't I/O
>after all.

    You talk about write-caching in drives being dangerous, and you're
advocating write-caching in the FS?  This is _far_ more dangerous.  It can
be useful, but it adds significant risks if the machine may be powered-off
unexpectedly, as desktop machines often are.  Write-caching makes sense on
a computer in a machine room, with well-conditioned power or even a UPS,
which is only shut off for maintenance.  It is not a very good idea for a
machine on someone's desktop.  Do you want to explain to Mr. Naive User
that you can't just save a file and switch the machine off?

--
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, [e-mail]  BIX: rjesup
Disclaimer: Nothing I say is anything other than my personal opinion.