balon@hpcupt1.cup.hp.com (Tom Balon) (04/24/91)
How do different versions of unix deal with new ZBR (Zone Bit
Recording)) style disk drives. These drives are divided into
several zones with a different number of sectors/track in each
zone.
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.
This may not work well with ZBR. For example, say we have a
disk with 1 to n zones. We build a 8K/1K file system on the disk.
In zone 1, the track size is 32K so we have 4 8K blocks per track,
in zone n, the track size is 24K so we have only 3 8k blocks per
track. Under these conditions, the old algorithm breaks down.
- Tom
***********************************************************************
* Tom Balon |{ucbvax, hplabs}!hpda!balon [UUCP] *
* Hewlett-Packard 47LF |balon@hpda.hp.com [INTERNET] *
* 19447 Pruneridge Ave |(408) 447-7116 [AT&T NET] *
* Cupertino, Ca. 95014 | *
***********************************************************************torek@elf.ee.lbl.gov (Chris Torek) (04/29/91)
In articles <68020001@hpcupt1.cup.hp.com> and <67930001@hpcupt1.cup.hp.com> balon@hpcupt1.cup.hp.com (Tom Balon) posts the same message separately to two newsgroups: >How do different versions of unix deal with new ZBR (Zone Bit Recording) >style disk drives. 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 BSD `Fast File System' does this. The old System V file system does not (it has a free list that rapidly gets scrambled, and essentially amounts to choosing a block at random). >This may not work well with ZBR. Actually, it works fine: >For example, say we have a disk with 1 to n zones. We build a [single] >8K/1K file system on the disk. In zone 1, the track size is 32K so we >have 4 8K blocks per track, in zone n, the track size is 24K so we have >only 3 8k blocks per track. Under these conditions, the old algorithm >breaks down. All this means is that the rotational placement tricks do not work well. Since most ZBR disks have caches in the controllers, this tends not to matter much. If the number of zones is small, you can use a gimmick: Make each partition cover a single zone, and use the number of sectors per track to make each file system on each partition. Many ZBR disks have too many zones to make this feasible (the Wren V, for instance, has something like 26 zones). It would not be too difficult to extend the BSD FFS algorithms to handle different zones---the rotational tables are read from the superblock and one could simply have one table per zone---but it would probably not be worthwhile. Those in search of a small thesis might try it anyway. :-) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
lm@slovax.Eng.Sun.COM (Larry McVoy) (04/29/91)
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