The rest of the paper is organized as follows. Section 2 discusses current logical volume managers and the need for Atropos. Section 3 describes the design an implementation of Atropos. Section 4 describes how Atropos is used by a database storage manager. Section 5 evaluates Atropos and its value for database storage management. Section 6 discusses related work. 2 Background This section overviews the design of current disk array LVMs, which do not exploit the performance benefits of disk-specific characteristics. It highlights the features of the Atropos LVM, which addresses shortcomings of current LVMs, and describes how Atropos supports efficient access in both column- and row-major orders to applications accessing two-dimensional data structures. 2.1 Conventional LVM design Current disk array LVMs do not sufficiently exploit or expose the unique performance characteristics of their individual disk drives. Since an LVM sits below the host’s storage interface, it could internally exploit diskspecific features without the host being aware beyond possibly improved performance. Instead, most use data distribution schemes designed and configured independently of the underlying devices. Many stripe data across their disks, assigning fixed-sized sets of blocks to their disks in a round-robin fashion; others use more dynamic assignment schemes for their fixed-size units. With a well-chosen unit size, disk striping can provide effective load balancing of small I/Os and parallel transfers for large I/Os [13, 16, 18]. A typical choice for the stripe unit size is 32–64 KB. For example, EMC’s Symmetrix 8000 spreads and replicates 32 KB chunks across disks [10]. HP’s AutoRAID [25] spreads 64 KB “relocation blocks” across disks. These values conform to the conclusions of early studies [4] of stripe unit size trade-offs, which showed that a unit size roughly matching a single disk track (32– 64 KB at the times of these systems’ first implementations) was a good rule-of-thumb. Interestingly, many such systems seem not to track the growing track size over time (200–350KB for 2002 disks), perhaps because the values are hard-coded into the design. As a consequence, medium- to large-sized requests to the array result in suboptimal performance due to small inefficient disk accesses. 2.2 Exploiting disk characteristics Track-sized stripe units: Atropos matches the stripe unit size to the exact track size of the disks in the volume. In addition to conforming to the rule-of-thumb as disk technology progresses, this choice allows applications (and the array itself [11]) to utilize track-based accesses: accesses aligned and sized for one track. Recent research [22] has shown that doing so increases disk efficiency by up to 50% for streaming applications that share the disk system with other activity and for components (e.g., log-structured file systems [17]) that utilize medium-sized segments. In fact, track-based access provides almost the same disk efficiency for such applications as would sequential streaming. The improvement results from two disk-level details. First, firmware support for zero-latency access eliminates rotational latency for full-track accesses; the data of one track can be read in one revolution regardless of the initial rotational offset after the seek. Second, no head switch is involved in reading a single track. Combined, these positioning delays represent over a third of the total service time for non-aligned, approximately track-sized accesses. Using small stripe unit sizes, as do the array controllers mentioned above, increases the proportion of time spent on these overheads. Atropos uses automated extraction methods described in previous work [21, 22] to match stripe units to disk track boundaries. As detailed in Section 3.3, Atropos also deals with multi-zoned disk geometries, whereby tracks at different radial distances have different numbers of sectors. that are not multiples of any useful block size. Efficient access to non-contiguous blocks: In addition to exploiting disk-specific information to determine its stripe unit size, Atropos exploits disk-specific information to support efficient access to data across several stripe units mapped to the same disk. This access pattern, called semi-sequential, reads some data from each of several tracks such that, after the initial seek, no positioning delays other than track switches are incurred. Such access is appropriate for two-dimensional data structures, allowing efficient access in both rowand column-major order. In order to arrange data for efficient semi-sequential access, Atropos must know the track switch time as well as the track sizes. Carefully deciding how much data to access on each track, before moving to the next, allows Atropos to access data from several tracks in one full revolution by taking advantage of the Shortest-Positioning- Time-First (SPTF) [12, 23] request scheduler built into disk firmware. Given the set of accesses to the different tracks, the scheduler can arrange them to ensure efficient execution by minimizing the total positioning time. If the sum of the data transfer times and the track switch times equals the time for one rotation, the scheduler will service them in an order that largely eliminates rotational latency (similar to the zero-latency feature for single track access). The result is that semi-sequential accesses are much more efficient than a like number of random or unorchestrated accesses.