Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!mandrill!nitrex!rbl
From: rbl@nitrex.UUCP
Newsgroups: comp.arch,comp.os.misc
Subject: Re: Unix File System Performance
Message-ID: <533@nitrex.UUCP>
Date: Sat, 19-Sep-87 11:18:33 EDT
Article-I.D.: nitrex.533
Posted: Sat Sep 19 11:18:33 1987
Date-Received: Sat, 26-Sep-87 16:33:24 EDT
References: <1384@faline.bellcore.com> <14704@topaz.rutgers.edu>
Reply-To: rbl@nitrex.UUCP ( Dr. Robin Lake )
Organization: The Standard Oil Co., Cleveland
Lines: 27
Xref: utgpu comp.arch:2205 comp.os.misc:215

In article <14704@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes:
>If you have a large proportion of short lived programs, wouldn't
>you say that you spend a lot of time just bringing the program in
>from disk.
>
>-Ron


And a lot of time bringing in the Unix utility programs that the applictions
may use...  Sugit Kumar did his Ph.D. dissertation at Case Western Reserve
(about 7 yr. ago) looking at the role of solid-state disks (experiments
were done on a PDP-11/45) in UNIX performance.  The best speed-ups were
by allocating one SSD to the system and utility programs and another SSD
to /usr/tmp.  If you're working against the same data files time and time
again in the application, copy it to SSD (/usr/tmp).  The speed up could
theoretically be about 17,000 fold, but the device drivers place a lower
bound on the access time.

What does this mean about file system performance?  ...  simply that the
overhead of the device driver and file system itself drops proportionately
if larger block sizes are used.  One trade off is "wasted" disk space for
smaller files.

Rob Lake
-- 
Rob Lake
{decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl