Xref: utzoo comp.unix.internals:2663 comp.unix.questions:30814
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!appserv!slovax.Eng.Sun.COM!lm
From: lm@slovax.Eng.Sun.COM (Larry McVoy)
Newsgroups: comp.unix.internals,comp.unix.questions
Subject: Re: File System and ZBR disks
Message-ID: <562@appserv.Eng.Sun.COM>
Date: 28 Apr 91 21:47:43 GMT
References: <12588@dog.ee.lbl.gov>
Sender: news@appserv.Eng.Sun.COM
Followup-To: comp.unix.internals
Organization: Sun Microsystems, Mt. View, CA.
Lines: 29

torek@elf.ee.lbl.gov (Chris Torek) writes:
> Most of them ignore the ZBR entirely.
> 
> >As I understand it, the unix file system uses the track size,
> >block/frag size, and information from the super block ( rotdly
> >for example ) in order to optimally allocate the next disk block.

The only place that you care at all is with large sequential files.
Small files fit in one block.  Given that information, you can make
zones be noise by allocating w/o any rot delay at all, detecting
sequential I/O, and switching to large (50-100KB) transfers.  If you do
that, the zone issue disappears into the noise.  

The fact that you have no rot delay is not interesting for randoms
and/or small files; all of those accesses look random to the disk.  

On place where rot delay could become interesting:  an idea that I've
beening toying with, is to notice when files are being read in a
particular directory (cat *.c).  If the files were all laid out w/ no
rot delays, you could conceivably have a FS that read all of them in at
once (can you say news? or /usr/include?).

I wrote paper about sequential performance stuff, it's in the last
Usenix.  I also left it (w/o permission, so it may get blown away) in
ucbarpa.berkeley.edu:/pub/mcvoy.clust.usenix.ps.Z because the guy from
HP wanted a look.  If someone knows of a better anon ftp spot, let me 
know (Sun doesn't provide one, bummer).
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com