Path: utzoo!attcan!uunet!husc6!think!ames!hc!lanl!unm-la!unmvax!turing.unm.edu!mike
From: mike@turing.unm.edu (Michael I. Bushnell)
Newsgroups: comp.unix.wizards
Subject: Re: Why UNIX I/O is so slow (was VAX vs SUN 4 performance)
Message-ID: <1121@unmvax.unm.edu>
Date: 18 Jun 88 22:37:06 GMT
References: <22957@bu-cs.BU.EDU> <14968@brl-adm.ARPA> <601@modular.UUCP> <23288@bu-cs.BU.EDU> <7980@alice.UUCP> <23326@bu-cs.BU.EDU> <6963@cit-vax.Caltech.Edu> <441@mn-at1.k.mn.org> <8124@brl-smoke.ARPA>
Sender: news@unmvax.unm.edu
Reply-To: mike@turing.unm.edu.UUCP (Michael I. Bushnell)
Organization: University of New Mexico, Albuquerque
Lines: 27

In article <441@mn-at1.k.mn.org> alan@mn-at1.UUCP (0000-Alan Klietz) writes:
>Berkeley should start over.  The whole business with "cylinder groups"
>tries to keep sets of blocks relatively near each other.  With the new
>disks today, the average SEEK TIME IS OFTEN FASTER THAN THE ROTATIONAL
>DELAY.  You don't want to keep blocks "near" each other, instead you want
>to make each extent as large as possible.  Sorry, but cylinder groups are
>archaic.

Yet Another Fast File System Misunderstanding (YAFFSM).

FFS doesn't try to put blocks "relatively near eachother" in the sense
you suggest.  It minimizes seek time by cylinder grouping, AND it minimizes
rotational delay by the allocation strategies inside cylinder groups.

Also, FFS does try to do big transfers.  8K is the norm for a block.  
Compare that to AT&T 512 byte!




-- 
                N u m q u a m   G l o r i a   D e o 

			Michael I. Bushnell
			HASA - "A" division
			mike@turing.unm.edu
	    {ucbvax,gatech}!unmvax!turing.unm.edu!mike