Observing the E ects of Multi-Zone Disks Rodney Van Meter
Information Sciences Institute
University of Southern California

Abstract
Current generations of hard disk drives use a technique known as zoned constant angular velocity (ZCAV), taking advantage of the geometry toincrease total disk capacity by varying the numberof disk sectors per track with the distance from thespindle. A side e ect of this is that the transfer rate
also varies with sector address. We analytically estimated and measured this e ect on le system performance on a BSD Fast File System, showing a drop ofroughly 25% in peak transfer rate depending on head
position. We also show that, while ZCAV e ects
cannot be ignored, a simple linear model adequately
estimates the performance from the few parameters
normally available in disk drive spec sheets.

1 Introduction
Many magnetic disk drives use a technique known aszoned constant angular velocity (ZCAV), taking ad-

vantage of the geometry to increase total disk capacity by varying the number of disk sectors per trackwith the distance from the spindle. A side e ect of
this is that the transfer rate also varies with block
address.
Despite some excellent recent work on modeling the behavior of disk drives [10, 14], the e ects
of ZCAV have generally not been taken into account in the design of le systems. Worthington
et al [13] built a disk model which includes zone
information, but the emphasis of their work is on
disk scheduling algorithms to reduce latency, rather
than improve throughput. Ghandeharizadeh hassuggested [4] that le placement be adjusted basedon access history to take advantage of ZCAV effects, but no work has measured the e ects directly.
 This research was sponsored by the Advanced Research
Projects Agency under Contract No. DABT63-93-C-0062.
Views and conclusions contained in this report are the authors' and should not be interpreted as representing the ocial opinion or policies, either expressed or implied, of ARPA,
the U.S. Government, or any person or agency connected withthem.

The Microsoft Tiger Video Server [2] uses a simple placement algorithm in which primary data isplaced on outer tracks and secondary (redundant,
infrequently-accessed) data is placed on inner tracks.
We estimated and measured the e ect of ZCAVon le system performance on a BSD fast le system, showing a drop of roughly 25% in peak transfer rate depending on head position. We also show
that, while ZCAV e ects cannot be ignored, a simple
linear model adequately estimates the performancefrom the few parameters normally available in disk
drive spec sheets.
The rest of the paper is organized as follows.
ZCAV is explained in detail in section 2. In section 3
we extract the zoning information for the disk driveused in our experimental analysis. In the following section an analytic model for estimating ZCAV
drive performance is presented. Then, our experimental setup is described, followed by our measured
results and conclusions.

2 Zoned Constant Angular
Velocity
Magnetic disk drives consist of one or more rotating platters on a common spindle. Data is written
and read by magnetic heads, generally one per surface (often with a spare surface, so that the number of heads is one less than twice the number ofplatters). A track is a concentric circle on one surface. The collection of tracks at the same distancefrom the spindle on each surface constitute a cylinder. A track consists of a number of sectors (occasionally called blocks), the smallest unit of data thatcan be read or written by the drive (typically 512
or 1024 bytes, but theoretically any number). The
triple <cylinder,head,sector> uniquely de nes alocation on the drive. See [10, 13] for good introductions to disk architecture.
ZCAV is a technique adopted by hard disk manufacturers to increase the capacity of disk drives.
Outer tracks, which are longer, contain more sec-

tors than the shorter inner tracks. The cylinders aregrouped into zones that all have the same numberof sectors per track. Some manufacturers refer tothis as Zoned Bit Recording, ZBR. It is referred toas notches or a notched drive in the Small Computer
Systems Interface (SCSI) speci cation [1].
As a side e ect of this, since the time per rotation is constant, the number of sectors read per second (and hence the transfer rate) is higher on outer
tracks. The read and write electronics must be able
to keep up with the higher data rates required.
Compact disks (hence, CD-ROM) and old 400KB
and 800KB Macintosh oppy drives achieved similar increases in density by varying the rotation
speed to achieve constant linear velocity. For highperformance hard disk drives this is impractical,
since each seek also means ghting high angular momentum to reach the correct speed, increasing thelatency on seeks to an unacceptable level.
As table 1 shows1 , the transfer rate of the outerzones of current disk drives from a major manufacturer exceeds that of the inner zones by factors ranging from 1.45 to 1.9. It is interesting to note thatthe disks with the highest capacity are not necessarily those with the highest ratio of inner to outertransfer rate.
The ST31200, for example, falls o from 47.2 to26.8 Mbps, a drop of 43%. Thus, if the disk is operating mainly in the inner regions of the disk, performance can be expected to fall to just over halfof the peak rate. Although not generally stated in
the user manuals for the disk drives, empirical evidence indicates that the lower-numbered blocks (fora SCSI command set interface) are stored on theouter tracks.
Note that these transfer rates are internal preformat transfer rates; we will use this information
to calculate the user data rate in the next section.
Manufacturers sometimes report an \average"
number of sectors per track for ZCAV disk drives.
This number appears to be arrived at by totallingthe number of sectors in the drive and dividing by
the number of tracks. It does not attempt to re ect
the fact that a higher percentage of the sectors arein tracks with more sectors. This average is usefulfor lling in the BSD disk format information (seethe manual pages for fs and newfs), which retains
the cylinder, head, sector model.

3 Determining Zone
Information
SCSI is a commonly used interface for disk drives,and all of the drives we deal with in this paper have
SCSI interfaces. At the SCSI command level, sectors
are referred to by a logical block address, which thedevice controller maps to a physical location.
Some information about the disk geometry is often available through the MODE SENSE Notch andPartition Page on SCSI disk drives. This page
reports the number of notches. The two drives used
for this paper, the ST31200 and the ST11200, bothreport 23 notches in this page. On some drives
it is possible to read some information about eachzone using MODE SELECT and MODE SENSE. However,
not all drives implement this functionality. The
ST31200 supports this, but the ST11200 does not.
The ST31200 only reports the number of cylinders
in a zone, however, not the number of sectors per
track or the total number of sectors in the zone.
More detailed information can be obtained byusing SEND DIAGNOSTIC and RECEIVE DIAGNOSTIC
with the TRANSLATE ADDRESS page. This provides
the cylinder, head and sector number for each logical block, allowing easy determination of the numberof sectors on a track, as well as two other important
performance factors: the delay incurred by switching
tracks and by switching cylinders, measured in sectors. It is interesting to note that on a Sparc 20/51
each address translation takes roughly 50 milliseconds, clearly at least one order of magnitude morethan the actual translation requires. The reason forthis delay is currently unknown.
The intratrack instantaneous transfer rate can be
determined by multiplying the number of bytes per
track by the revolutions per second,
bytes
track



revs
secondTo nd the sustained user rate for long transfers,
this must be multiplied by the factor + ( ? 1)  t + c
h

h

s

h

s

g

g

where is the number of heads (tracks per cylinder), is the sectors per track, t is the trackswitch skew (gap) (measured in sectors) and c is thecylinder-switch skew (also in sectors). When reading
continuously, the drive executes ? 1 track switches
plus one cylinder switch, per cylinder read.
Table 2 gives the detailed zone information
for the Seagate ST11200 used in these experih

s

g

g

h

Most of these values were retrieved from Seagate's web
site (http://www.seagate.com), but the availability of data
there varies.
1

Drivecapacity min internal max internal(GB)xfer ratexfer rate(Mbps)(Mbps)
Barracuda ST11950
1.69
34.3
56.5
Barracuda ST32171
2.25
75
120
Elite ST43400
2.9
35
52
Decathlon S5850A
0.71
32.45
61.65
Hawk 4 ST15230
4.29
34
61
Hawk 2XL ST31051
1.05
44
66
Elite ST410800
9.09
44
65
ST31200
1.06
26.8
47.2
ST11200
1.05
23.2
40.6

ratio
1.65
1.60
1.49
1.90
1.79
1.50
1.47
1.76
1.75

Table 1: Transfer Rates for a Variety of Seagate Disks

zone
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

start
0
205
235
328
361
429
573
611
689
768
888
969
1010
1090
1169
1326
1504
1539
1707
1789

cyls heads sec/trk
205
15
94
30
15
93
93
15
92
33
15
91
68
15
88
144
15
84
38
15
83
78
15
80
79
15
77
120
15
76
81
15
75
41
15
74
80
15
73
79
15
71
157
15
65
178
15
62
35
15
61
168
15
57
82
15
56
80
15
54

zonesec
28905041850
12834045045
89760
181440
47310
93600
91245
136800
91125
45510
87600
84135
15307516554032025
14364068880
64800

totsec MB/sec. trotgap crotgap adjMBs
289050
4.34
18
28
3.62
330900
4.29
17
28
3.61
459240
4.25
17
27
3.56
504285
4.20
17
27
3.52
594045
4.06
17
26
3.39
775485
3.88
16
25
3.24
822795
3.83
16
25
3.19
916395
3.69
15
24
3.09
1007640
3.56
15
23
2.96
1144440
3.51
15
23
2.91
1235565
3.46
14
22
2.90
1281075
3.42
14
22
2.86
1368675
3.37
14
22
2.81
1452810
3.28
14
21
2.72
1605885
3.00
13
20
2.49
1771425
2.86
12
19
2.38
1803450
2.82
12
19
2.34
1947090
2.63
11
18
2.19
2015970
2.59
11
17
2.15
2080770
2.49
11
17
2.06

Table 2: Extracted Zone Information for ST11200 with Calculated Transfer Rates

ments. This data was obtained by a modi ed version of John DiMarco's scsiinfo, using a SENDDIAGNOSTIC/RECEIVE DIAGNOSTIC RESULTS
command pair with the TRANSLATE ADDRESS pagefor each block on the disk, then hand-extracting thezone boundaries. On disks that also support setting the active notch on the MODE SELECT Notch
and Partition Page, it is possible to more directly
extract the cylinder boundaries. The ST31200, forexample, returns the notch size in cylinders, but not
the total sectors in the notch. Determining the notchboundaries is also complicated by the track skew,
sparing of sectors, and sector remaps. The capacity of each zone as listed does not take into accountremapped or skipped sectors.
In table 2, the rst column is zone number, starting from the outer edge, in accordance with blocknumbering. start is the cylinder number for the startof the zone. cyls is the number of cylinders in thezone. heads, the number of data heads used, is constant for the whole disk drive. sec/trk is the numberof sectors per track in the zone. zonesec, the total number of sectors in the zone, is the product ofthe prior three columns; totsec is a running total of
the zonesec column. The columns in the table labeled trotgap and crotgap are the track and cylinderskew. MB/sec. is the intratrack transfer rate determined as above, and adjMBs is the rate adjusted
by the track and cylinder skew, as above. As thetable shows, the reduction in transfer rate causedby fewer sectors in a zone can sometimes be almost
completely o set by a reduction in the track skew.
Compared with the values of 23.2 to 40.6 Mbps internal transfer rates cited in the manufacturer's manual, the adjusted values are 29% lower, and represent
reasonable \not to exceed" values for system transfer
rates. It is also worth noting that the drive reports
23 notches on the notch and partition page, but only
twenty were discernable from the logical to physicalblock map. The transfer rate is graphed in gure 1,
which is explained in detail in section 4.

4 Analytic Approach to
Estimating Performance
In this section, we consider three abstract examples, then analyze the disk drive used for the experiments. Transfer rates here are quoted in sectors per revolution; multiplying by revolutions per
second and bytes per sector (both constants) would
give bytes/second.
The rst example is a hypothetical three-zoned
disk drive. The outer zone is 100 tracks of 175 sec-

tors, the middle zone is 100 tracks of 137 sectors, andthe inner zone is 100 tracks of 100 sectors. This isoverly simplistic but the ratios are common. The total capacity of the drive is 100  175+100  137+100 
100 = 41200 sectors. Roughly 42% of the sectors arein the outer zone, 33% in the middle zone, and 24%
in the inner zone. Figure 2 shows the transfer ratein each zone versus track number. Figure 3 plots thetransfer rate versus block number. Note the di erent position of the boundary between zones relative
to gure 2, due to the higher capacity of the outerzones.
The \average" number of sectors per track is137. If we assume that each sector is accessedwith equal frequency, the \average" transfer rate is(17500  175 + 13700  137 + 10000  100) 41200, or
144 sectors/revolution, due to the higher probability of being in a high-sectors-per-track zone. Thise ect alone leads to an error of 5% when estimating performance based solely on the mean numberof sectors per track.
As a second example, consider a more nelygrained zoning. Let the disk drive consist of one
track of 175 sectors, one of 174 sectors, etc. down toan inner track of 100 sectors, for a total capacity
of
X 
=
i i
=

C

C

i2Z

s

t

where i is the number of sectors per track in zone
, i is the number of tracks in the zone, and is theset of zones. In this case, i = 175 ? and i = 1, so
this reduces to
s

i t

Z

s

i

t

X = 10 450
=
175

C

i=100

i

;

sectors. The mean number of sectors per track is
10 450 76 = 137 5
Figure 4 shows transfer rate versus track number.
Figure 5 shows the transfer rate versus block address for this example. Visually, it is nearly linear.
A small 2 factor would be expected to cause thetransfer rate to fall o more quickly at higher blocknumbers (fewer sectors per track mean fewer sectors
per zone, meaning the advance to yet-smaller zones
accelerates), as shown in gure 5. However, this factor appears to be unimportant, to rst order.
The median transfer rate med is the transfer rateof block number 2. In this case, block 5225 is on
track 143, so it has a transfer rate of 143, 4% higher
than the mean sectors per track.
The \average" transfer rate, again assuming equal
probability of access for each sector, would be the
;

=

:

n

R

C=

Transfer Rate as a Function of Block Address, ST11200
4.0
actual xfer rate
linear estimate
3.5

Transfer Rate (MB/sec.)

3.0

2.5

2.0

1.5

1.0

0.5

0.0
0

5000001000000
Sector Address (512 byte)

1500000

2000000

Figure 1: ST 11200 Zones with Calculated Transfer Rates

Transfer Rate as a Function of Track Number
200
transfer rate

Transfer Rate

150

100

50

0
0

50

100

150
Track Number

200

Figure 2: Three large zones, transfer rate v. track no.

250

300

Transfer Rate as a Function of Block Address200
transfer rate

Transfer Rate

150

100

50

0
0

5000

10000

15000

20000
25000
Block Address

30000

35000

40000

Figure 3: Three large zones, transfer rate v. block no.

Transfer Rate as a Function of Track Number
200
transfer rate

Transfer Rate

150

100

50

0
0

10

20

30

40
Track Number

50

60

Figure 4: Single-track Zones, transfer rate v. track no.

70Transfer Rate as a Function of Block Address200
transfer rate
linear estimate

Transfer Rate

150

100

50

0
0

2000

4000

6000
Block Address

8000

10000

Figure 5: Single-track Zones, transfer rate v. block no.
sum of the transfer rates for each of the individual
blocks, divided by the total number of blocks:
R

Pi2Z i  i
Pi2Z i  i= P
i2Z i  i

ba =

2

t

2

t

s

t

s

C

s

This will not be equal to the \average" sectors
per track reported by the manufacturer, times therotations per second:
avg:bytes

=

bytes



avg:sectors

rotationsP
In our example 2, ba simpli es to isecondsectorrotationsecond=(1 801 800 ? 328 350) = 1 473 450 10 450 =
141, a very modest 2.5% increase from simply assuming it to be the mean of the max and min transfer rates. For all practical purposes, therefore, we
can estimate the mean transfer rate as the mean of
min and max, when the zoning is ne-grained androughly linear with track number.
Figure 6 shows transfer rate versus block address
for the Seagate ST31200, calculated based on the extracted zone information. It clearly shows the e ectsof more of the blocks being in the outer zones. The
median transfer rate is 3.6 MB/sec, 10% higher than
175
=100 i=C

R

;

;

;

=C

;

;

=

;

the 3.25 arrived at by averaging the max and min
rates. The average transfer rate, assuming each sector has equal probability of being accessed, is 3.47,
still 6% higher than 3.25. Again, the curve varies
only slightly from linear.
Figure 1 shows the transfer rate plotted against
sector address for the ST11200 used for these experiments. A simple linear estimate is also plotted,
running from the transfer rate at the outermost zone
to the innermost zone. This shows a rough t, withthe maximum error from the true rate being approximately 8%. Thus, while far from perfect, this exceedingly simple model is signi cantly more accurate than assuming a xed transfer rate, which mayvary by 40%. In addition, this can be easily estimated from the data sheets typically supplied withdisk drives.
A recommended rst-order estimate of transfer rate, simple enough to be implemented in aguaranteed-I/O-rate le system, would therefore be( ) = 0 7 max ? 0 7( max ? min ) 

R x

: r

:

r

r

C

(1)

x

where is the disk capacity and max and min
are the maximum and minimum internal transfer
rates reported by the disk drive manufacturer. The
factor 0.7 comes from our observation in section 3Crr

Transfer Rate as a Function of Block Address, ST31200
5
actual xfer rate
linear estimate

Transfer Rate (MB/sec.)

4

3

2

1

0
0

5000001000000
Sector Address (512 byte)

1500000

2000000

Figure 6: ST 31200 Zones with Calculated Transfer Rates
that transfer rates adjusted for sector overhead, error correction and track and cylinder skew results
in a drop of approximately 29% from the manufacturer's listed transfer rates, which are instantaneous
bit rates at the read/write head. Because this data
is readily available, this factor can be incorporated
quickly and easily by le system and device driver
designers, without the necessity of tediously testing each possible disk drive. This transfer rate, ofcourse, must be adjusted by the system's ability tosustain the I/O rate; as shown above, for a Sparc
10 running SunOS and a FFS, reads can run at device speeds, while writes run at approximately 80%of theoretical.

has 23 zones, or notches, and an average (mean) of
73 sectors per track, 15 heads, 1,872 cylinders fora total of 28,080 tracks. The drive rotates at 5,411
rpm. Write caching at the disk is disabled; all writes
are synchronous.

5 Experiment

The le system is a SunOS UFS, essentially a BSD
fast le system [5]. The partition used for these experiments begins at sector number 655,200 and extends 687MB to the end of the disk, as reported bydkinfo. Thus, according to table 2, the partition
starts at a transfer rate of 3.24 MB/sec. and falls to
2.06, a drop of 36%. Unfortunately, due to hardware
and disk partitioning limitations, it was not possibleat the time this experiment was conducted to cover
the entire span of a disk.

These experiments were conducted on a Sparcstation 10 with 64 MB of main memory, and a 1.05
GB Seagate ST11200N disk drive. The actual bandwidth of this disk drive, as shown in table 2, varies
from approximately 2.06 to 3.62 MB/sec., a factorof 1.75. Any read or write rate that exceeds that has
clearly been the bene ciary of caching, either the lesystem's bu er cache or the disk drive's data block
cache. According to the manual [11], this disk drive

The basic experiment runs a loop that executesa modi ed version of Tim Bray's bonnie to write
a 100MB le, unmount the partition (to clear thecache and commit all modi ed metadata), then readthe le back. Then the script records the Bonnie
data le layout, deletes the le, writes a 10MB leto the system, and repeats. Thus, we have the results for 100MB written at 10MB intervals. The freespace falls from approximately 610MB (user space
available) to 105MB in 50 steps.

5.1 Experimental Setup5.2 Experimental Data

When measuring the e ects of the ZCAV layout onle system performance, care must be taken as numerous other factors can contribute to changes in
performance. They include: distance from metadata (increased seek times) free space fragmentation
 CPU performance and system loading
 bu er cache page replacement performance
Of course, the e ect on performance will vary dramatically with the le system structure, which is
generally operating-system speci c; this is coveredin the following section.
Our data shows that the write rate varies by afactor of 1.33 (2528 KB/sec. v. 1900 KB/sec., adrop of 25%) depending on head position, even overthe limited range of our experiments. Evaluating thereads is more dicult due to the high variability, but
if we choose the means from the same data runs as
the writes, we see a 23% drop, 3295 KB/sec. v. 2547
KB/sec. at, respectively, 608 and 270 MB free.
Figure 7 shows the mean of ten runs2 of our
100/10 benchmark. The error bars are 90% con dence intervals. Writes are also plotted with error
bars, but they are too small to see at many data
points. The results clearly show a drop in performance as the disk lls, until with about 280MB freespace the curve takes a sharp, unexpected upwardturn.
The write values are lower than the theoreticalmaximum due to inevitable missed rotations. Since
the disk is not allowed to cache write data, typicallyat least one rotation must be missed at the end ofeach write request. Additionally, occasionally thele system writes some metadata to the drive, requiring a seek and write, with ensuing missed rotations. The measured values are fairly consistently
approximately 80% of the calculated values, indicating approximately one missed rotation in ve.
Examining the layout for the data les created by
the Bonnie benchmark (examined using a modi ed
version of Keith Smith's fsblks utility), as shown ingure 8, con rms the hypothesis that transfer rate
is related to head position, as well as providing an
explanation for the upward turn near the right-handedge. The 10 MB ller les are getting laid down
2 The runs actually used for these calculations are numbers
6 through 15; the rst ve representedprogressive re nementsof the measurement code and are discarded.

with holes between them which go unused until the
disk nears full.
Returning to gure 7, the points labeled calc are
calculated from run number 9, estimating the performance by integrating the transfer rate at each blockin the le, using the transfer rates calculated for eachzone in section 3. It clearly shows the same features (dips and peaks) as the write and read curves.
The slight di erence (approximately 5%) between
the read curve and the calculated estimate is because
the calculated estimate does not take into accountreal-world overheads for command processing andlatency, and CPU time in the kernel and user process. This di erence (for both read and write) will
be system dependent and will have to be determined
empirically.
The points labeled lin-est are calculated using thelinear estimate shown in equation 1. The largest difference from the more correctly calculated values is
7%. This error is signi cant, but the simplicity ofthis linear estimate (both in ease of determinationand ease of use) may make it an acceptable substitute for detailed zone calculations. The apparent better agreement of the linear estimate than the
more realistic calculation above is coincidence; thelinear estimate slightly underestimates performancecompared to the non-linear e ects of block addressand geometry as described in section 4. Note thatnear the disk spindle (where the curve in gure 7
dips at 280,000 KB free), the agreement between
the block calculation and linear estimate is better,as we would expect.
Reviewing our concerns expressed at the top of
this section, our data has good repeatability, especially on writes. The bu er cache issue has beenaddressed by clearing the cache via remounting thepartition. Free space fragmentation proved to not be
a problem. The CPU and other system components
appear to be up to the task of fully utilizing the disk,
clearly showing the ZCAV e ects we expected.

6 Conclusions

6.1 Dependence on File System
Structure

One of the interesting aspects of this work is how repeatable the data proved to be, especially for writes.
This clearly demonstrated that the SunOS le allocation code depends on the current state only; therecent history of le creations and deletions does notalter future le system allocation decisions. Notethat this does not mean that disk fragmentation isTransfer Rate as a Function of Free Disk Space
3500
read
write
calc
lin-estTransfer Rate (KB/sec)

3000

2500

2000

1500
700000600000500000400000300000Free Space (KB)

2000001000000

Figure 7: 10 runs of 100/10 ZCAV benchmark

Blocks Allocated to Bonnie Datafile0
blocks in use
avg. file posn
100000

block address

200000300000400000500000600000700000700000600000500000400000300000free space

Figure 8: File layout for run # 7

2000001000000not a general problem, only that once large areas ofdisk have been cleared of les, the reuse of that area
is optimal (or at least predictable).
McVoy showed that a UFS can achieve good write
performance [6]3. The le blocks are allocated contiguously and I/Os are performed in clusters, much
like an extent-based le system. Our work bene ts
from this work.
Other possible le system structures, such as
SGI's XFS [12], may depend on more dynamic, andhence complex, data structures, and may therefore
not allocate blocks as predictably. A log-based lesystem [9] or disk device [3] clearly will not, in theirpresent forms, allocate blocks in a fashion amenable
to improving throughput by careful choice of blocks.

6.2 Impact on File System Allocation
Policies

As proposed by Ghandeharizadeh [4], the idea ofincluding a measure of ZCAV e ects into a dynamic
le relocater is appealing. Such functionality could
be included in a le system defragmenter, moving
older, less-frequently-accessed les to lower-transferrate areas of the disk.
It is clear that this e ect needs to be taken into
account for multimedia le systems and le systems (such as SGI's XFS [12] or Rangan's multimedia ropes [8]) that provide guaranteed throughput. However, to date these have all assumed disk
bandwidth is xed, rather than a function of block
address.
Larger les accessed in large chunks, for whichtransfer rate is likely to be more important, shouldbe allocated to blocks at the outer edges (for a Seagate SCSI drive, the lower-numbered blocks). Smallles obviously do not need to be placed in a hightransfer rate location, as their transfer time will bedominated by latency. Large les accessed in small
I/O requests also will not take good advantage ofthe transfer rate. Determining which les will takeadvantage of this may require cooperation from applications, perhaps via some form of hints [7].
Incorporating knowledge of the drive's ZCAV nature into the cleaner for a log-structured le system may be useful. Data should be packed toward
the spindle, so that the open area for upcoming log
writes will get to use the outer, faster regions of the
disk. This could be expected to improve the write
performance of the LFS by 25% or more, at the ex3 McVoy noted, in fact, that exposing the drive's variablegeometry to the system will complicate block allocation, especially in an extent-base FS.

pense of slower reads, in keeping with the LFS philosophy.

6.3 Future Work
Obviously, we would like to try these experiments on
a wider range of hardware and software platforms,
especially di erent le systems. However, the pointthat performance varies with head position appears
to have been adequately demonstrated. In particular, our work should be repeated with di erent families of disk drives from di erent manufacturers, tocon rm both the hypothesis that ZCAV e ects areuser-visible, and the e ectiveness of our proposed
linear estimate.
Ideally, a publicly-available bank of information
on drive types and zone information should be created. As more drive developers adopt standard
methods of determining the zone information, ofcourse, determining this information at boot timeor le system con guration time becomes more feasible.

6.4 Conclusions
We have explained the underlying motivations behind ZCAV disk drives, and demonstrated that it
does have an e ect on le system performance for a
BSD FFS. We have shown that it is possible, thoughsomewhat tedious, to extract this information fromat least some disk drives directly. We have proposedthat a simple linear model relating transfer rate toblock address should be adequate for most purposes.
The measurable e ect, at 23-25%, is less than thephysical di erence of 36% between the inner andouter disk edges of the tested partition, but still toolarge to ignore in performance-critical applications.

Acknowledgments
This work would have been substantially more tedious if not for the generosity of Keith Smith(fsblks), John DiMarco (scsiinfo) and Tim Bray(bonnie) in making their code publicly available.
John Heidemann, Ted Faber and Greg Finn provided useful technical and editorial suggestions. The
anonymous referees and my shepherd, Bill Bolosky,
improved the paper through their comments as well.

References[1] ANSI. Information Technology - Small Computer Systems Interface - 2 (X3T9.2 rev 10l),
Sept. 1993.
[2] W. J. Bolosky et al. The tiger video leserver.
In Proc. Sixth International Workshop on Net-

work and Operating System Support for Digital Audio and Video, Apr. 1996. available

at ftp://ftp.research.microsoft.com/pub/techreports/Winter95-96/TR-96-09.ps.

[3] W. de Jonge, M. F. Kaashoek, and W. C. Hsieh.
The logical disk: A new approach to improving
le systems. In Proc. Fourteenth ACM Symposium on Operating Systems Principles, pages
15{28, Dec. 1993.
[4] S. Ghandeharizadeh, D. J. Ierardi, D. Kim, andR. Zimmerman. Placement of data in multizone disk drives. rcvd from author, June 1995.
[5] S. J. Leer, M. K. McKusick, M. J. Karels, andJ. S. Quarterman. The Design and Implementation of the 4.3BSD UNIX Operating System.
Addison-Wesley, 1989.
[6] L. W. McVoy and S. R. Kleiman. Extentlike performance from a UNIX le system. In

Proc. 1991 USENIX Winter Technical Conference, pages 33{43. USENIX, 1991.

[7] R. H. Patterson, G. A. Gibson, E. Ginting, D. Stodolsky, and J. Zelenka. Informed
prefetching and caching. In Proc. 15th Annual
ACM Symposium on Operating Systems Principles, pages 79{95. ACM, Dec. 1995.

[8] P. V. Rangan and H. M. Vin. Designing lesystems for digital video and audio. In Proc.
Thirteenth ACM Symposium on Operating Systems Principles, pages 81{94, Oct. 1991.

[9] M. Rosenblum and J. K. Ousterhout. The design and implementation of a log-structured lesystem. In Proceedings of the 13th Symposium
on Operating Systems Principles, pages 1{15.
ACM, Oct. 1991.
[10] C. Ruemmler and J. Wilkes. An introduction
to disk drive modeling. Computer, 27(3):17{28,Mar. 1994.
[11] Seagate. Product Manual - Hawk 1 Family
SCSI-2 (Volume 1), Rev. D, 1994.

[12] A. Sweeney, D. Doucette, W. Hu, C. Anderson,
M. Nishimoto, and G. Peck. Scalability in the
XFS le system. In Proc. 1996 USENIX Technical Conference, pages 1{14. USENIX, Jan.
1996.
[13] B. L. Worthington, G. R. Ganger, and Y. N.
Patt. Scheduling for modern disk drives andnon-random workloads. Technical Report CSETR-194-94, University of Michigan, Mar. 1994.
[14] B. L. Worthington, G. R. Ganger, Y. N. Patt,
and J. Wilkes. On-line extraction of SCSI disk
drive parameters. In Proc. ACM Sigmetrics
Conference, May 1995.

Availability
The code used for these measurements anddata obtained is available on the web at
http://www.isi.edu/netstation/zcav/ or on the author's home page at http://www.isi.edu/~rdv/ or
http://alumni.caltech.edu/~rdv/.
The author may be contacted via email atrdv@isi.edu or rdv@alumni.caltech.edu.