The Vinum volume manager

Previous Sections

Introduction
The problems
Current implementations
How Vinum addresses the Three Problems
The big picture
Some examples
Increased resilience: RAID-5
Object naming
Startup
Performance issues
The implementation
Driver structure

Driver structure

Vinum can issue multiple disk transfers for a single I/O request: The second set of RAID-5 operations and I/O recovery do not match well with the design of UNIX device drivers: typically, the ``top half'' of a UNIX device driver issues I/O commands and returns to the caller. The caller may choose to wait for completion, but one of the most frequent uses of a block device is where the virtual memory subsystem issues writes and does not wait for completion.
UNIX device drivers run in two separate environments. The ``top half'' runs in the process context, while the ``bottom half'' runs in the interrupt context. There are severe restrictions on the functions that the bottom half of the driver can perform.

This poses a problem: who issues the second set of requests? The following possibilities, listed in order of increasing desirability, exist:

Initially, Vinum used the fourth solution. This worked for most drivers, but some drivers required functions only available in the ``top half'', such as malloc for ISA bounce buffers. Current FreeBSD drivers no longer call these functions, but it is possible that the situation will arise again.

On the other hand, this method does not allow I/O recovery. Vinum now uses a dæmon process for I/O recovery and a couple of other housekeeping activities, such as saving the configuration database. The additional scheduling overhead for these activities is negligible, but it is the reason that the RAID-5 second stage does not use the dæmon.

Following Sections

Availability
Future directions
References