File System and ZBR disks

[Chris Torek]

In articles <68020001 at hpcupt1.cup.hp.com> and <67930001 at hpcupt1.cup.hp.com>
balon at 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 at ee.lbl.gov