Xref: utzoo alt.sys.sun:2074 comp.periphs.scsi:1378 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!csus.edu!ucdavis!csusac!unify!srm From: srm@Unify.Com (Steve Maraglia) Newsgroups: alt.sys.sun,comp.periphs.scsi Subject: Re: Which Sun Disks to use? SCSI vs IPI vs SMD? Message-ID: <746y7as@Unify.Com> Date: 16 Nov 90 21:12:45 GMT References: <1990Nov14.015823.27206@Neon.Stanford.EDU> <1990Nov14.051828.4221@cbnewsh.att.com> Distribution: na Organization: Unify Corporation, Sacramento, CA, USA Lines: 81 >In article srm@Unify.Com (Steve Maraglia) writes: > >>In article <1990Nov14.051828.4221@cbnewsh.att.com> wcs@cbnewsh.att.com (Bill Stewart 201-949-0705 erebus.att.com!wcs) writes: >> >>We're planning to get a Sun server for NFS, and are trying to decide whether >>to get a cheap Sparcstation with SCSI, a Sparc2 with SCSI, >>or one of the big honking expensive servers with IPI or SMD. >>Are the SCSI systems fast enough? Will UNIX 4.1.1 help performance >>substantially on the pre-Sparc2 machines? >> > >Since those big honking expensive servers don't fit very well into >our budget I'm considering a SPARCstation 2 as a server. I just got >off the phone with a Sun SE and have a few pieces of information that >may be of interest. > >Besides having the highest MIP rating in the product line they have made >some big improvements in I/O performance. > >Two big factors for the improvment are: > > 1. The kernel enhancements for the DataBase Accelerator package have > been included in 4.1.1. > I stand corrected on item 1. by another Sun S.E. who has some additional performance comments. See below. > On Nov 14, James Litchfield - Sun Major Accounts Region SE writes: > > > 1. The kernel enhancements for the DataBase Accelerator package > have > > been included in 4.1.1. > > Only those parts of DBE directly related to the PMEG problem have > been incorporated. Other parts of DBE are not part of 4.1.1. You should > probably correct your statement. > > > You should also consider the following tidbit for 4.1.1 - I/O > clustering. > > >From the RTF: > > The Unix File System (UFS) has been modified to make use of I/O > clustering. Clustering improves sequential I/O performance by > writing files to disk in physically contiguous blocks whenever > possible. Although it has long been possible to tune UFS to write > contiguous blocks, it has rarely been done, beacuse write performance > suffers. Clustering is a different approach. > > Under previous SunOS operating systems, UFS responded to each I/O > request by reading or writing a single block (usually 8KB) of data. > Since data is written to a spinning disk and between each response > to an I/O request there is a brief time delay, it is impossible to > write contiguous disk blocks while the disk is spinning unless the > write waits for the disk to rotate back to the point of the previous > write. Writing a large file to contiguous disk blocks would require a > large number of individual I/O requests and write delays. > > In SunOS 4.1.1, UFS has been modified to cluster I/O requests into > extents and read or write an entire extent in a single I/O operation. > The size of an extent can be controlled by setting the file system > parameter maxcontig (see tunefs(8)). Since extents reduce the number of > I/O operations necessary, there are fewer delays between writes and > fewer rotational delays. > > File systems created with the newfs command use I/O clustering and > are automatically tuned for high performance. However, the benefits of > clustering may decline if a filesystem created under newfs starts to > fill > up and is heavily fragmented from the repeated addition and deletion > of files. In addition, filesystems using 4KB blocks on 8KB page systems > do not benefit from I/O clustering and are not recommended. -- Steve Maraglia internet: srm@unify.com Unify Corporation ..!{uunet,csusac,pyramid}!unify!srm 3870 Rosin Court Sacramento, CA 95834 (916) 920-9092