lm@slovax.Eng.Sun.COM (Larry McVoy) (05/08/91)
Archive-name: research/filesystems/mcvoy-cluster-usenix/1991-04-28 Archive: ucbarpa.berkeley.edu:/pub/mcvoy.clust.usenix.ps.Z [128.32.130.11] Original-posting-by: lm@slovax.Eng.Sun.COM (Larry McVoy) Original-subject: Re: File System and ZBR disks Reposted-by: emv@msen.com (Edward Vielmetti, MSEN) 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 -- comp.archives file verification ucbarpa.berkeley.edu -rw-r--r-- 1 1092 163 63095 Apr 25 17:07 /pub/mcvoy.clust.usenix.ps.Z found mcvoy-cluster-usenix ok ucbarpa.berkeley.edu:/pub/mcvoy.clust.usenix.ps.Z