Enterprise Volume Management System

Documentation

Screen Shots

Downloads

Hosted By:

EVMS Terminology

Because of the different terms used to describe volume management on operating systems, we developed a set of terms specific to EVMS. This section defines some general terms used in EVMS and defines the different layers used with EVMS.

General Terms

The following list defines volume management terms as they relate specifically to EVMS.

Sector: The lowest level of addressability on a block device. This definition is in keeping with the standard meaning found in other management systems. In most situations, a sector is 512 bytes.
Storage Object: Any memory structure in EVMS that is capable of being a block device. An ordered set of sectors.
Logical Disk: The ordered set of sectors that represents a physical device. IDE and SCSI disks appear as Logical Disks in EVMS.
Disk Segment: An ordered set of physically contiguous sectors residing on a logical disk or on another disk segment. The general analogy for a segment is to a traditional disk partition, such as in DOS or OS/2Ž.
Storage Region: An ordered set of logically contiguous sectors (that are not necessarily physically contiguous). The underlying mapping can be to logical disks, segments, or other regions. Linux LVM and AIX LVM LVs, as well as MD devices, are represented as regions in EVMS.
Storage Container: A collection of storage objects. Storage containers provide a re-mapping from this collection to a new set of storage objects that the container exports. The appropriate analogy for a storage container is to volume groups, such as in the AIXŽ LVM and the Linux LVM. However, EVMS containers are not restricted to any one remapping scheme, as is the case with volume groups in LVM or AIX. The remapping could be completely arbitrary.
Feature Object: A logically contiguous address space created from one or more disks, segments, regions or other feature objects through the use of an EVMS native feature. Feature Objects are essentially the same as Regions, except that Feature Objects contain EVMS-specific metadata.
EVMS Logical Volume: A mountable storage object. EVMS volumes contain metadata at the end of the underlying object, and at a minimum will have a static name and static minor number. Any object in EVMS can be made into an EVMS volume.
Compatibility Logical Volume: A mountable storage object that does not contain any EVMS native metadata. Many plug-ins in EVMS provide support for the capabilities of other volume management schemes. Volumes that are designated as "compatibility" are insured to be backwards compatible to that particular scheme because they do not contain any EVMS native metadata. Any disk, segment, or region can be a compatibility volume. Howevever, Feature objects cannot become compatibility volumes.

Layer Definitions

EVMS defines a layered architecture where plug-ins in each layer create abstractions of the layer(s) below. EVMS also allows most plug-ins to create abstractions of objects within the same layer. The following list defines these layers from the bottom up.

Logical Device Managers

The first layer is the logical device managers. These plug-ins communicate with the hardware device drivers to create the first EVMS objects. Currently, all local devices (most IDE and SCSI disks) are handled by a single plug-in. Future releases of EVMS might have additional device managers to do network device management, such as for disks on a storage area network (SAN).

Segment Managers

The second layer is the segment managers. In general, these plug-ins handle the segmenting, or partitioning, of disk drives. The engine components can replace partitioning programs, such as fdisk and disk druid, and the kernel components can replace the in-kernel disk partitioning code. Segment managers can also be "stacked," meaning that one segment manager can take input from another segment manager.

Currently, there are three plug-in in this layer. The most commonly used is the DOS Segment Manager. This plug-in handles the DOS partitioning scheme, which is the scheme traditionally used by Linux. This plug-in also handles some special cases that arise when using OS/2 partitions. There is also a plug-in to handle the new GPT partitioning scheme on IA-64 machines, and a plug-in to handle S/390 partitions (CDL/LDL/CMS). Both of these plug-ins are still in development, and only support discovery and the I/O path. Other segment manager plug-ins may be added for supporting other partitioning schemes (e.g. Macintosh, Sun, and SGI).

Region Managers

The third layer in EVMS is the region managers. This layer is intended to provide a place for plug-ins that ensure compatibility with existing volume management schemes in Linux or other operating systems. Region managers are intended to model systems that provide a logical abstraction above disks or partitions.

Like the segment managers, region managers can also be stacked. Therefore, the input object(s) to a region manager can be disks, segments, or other regions.

There are currently four region manager plug-ins in EVMS. The first is the LVM plug-in that provides compatibility with the Linux LVM and allows the creation of volume groups or containers and logical volumes or regions.

Two more plug-ins are the AIX and OS/2 region managers. The AIX LVM is very similar in functionality to the Linux LVM, and uses volume groups and logical volumes. The AIX plug-in is still under development. It currently provides most necessary kernel functionality, but is still limited in user-space. The OS/2 plug-in provides compatibility with volumes created under OS/2. Unlike the Linux and AIX LVMs, the OS/2 LVM is based on the linear linking of disk partitions, as well as bad-block-relocation.

The fourth region manager plug-in is the Multi-Disk (MD) plug-in for RAID. This plug-in provides RAID levels linear, 0, 1, 4, and 5 in software. The ability to stack region managers allows combinations of RAID and LVM. For instance, a stripe set (RAID 0) could be used as a PV in LVM, or two LVM LVs could be mirrored using RAID 1.

EVMS Features

The next layer is EVMS Features. This layer is where new EVMS-native functionality is implemented. EVMS Features can be built on any object in the system, including disks, segments, regions, or other feature objects. EVMS Features all share a common type of metadata, which makes discovery of Feature objects much more efficient, and recovery of broken Features objects much more reliable.

There are three Features currently available in EVMS. The first Feature is Drive Linking. This plug-in simply allows any number of objects to be linearly concatenated together into a single object.

The second Feature is Bad-Block-Relocation (BBR). BBR monitors its I/O path and detects write failures (which may be caused by a damaged disk). In the event of such a failure, the data from that request is stored in a new location. BBR keeps track of this remapping, and any additional I/Os to that location are redirected to the new location.

The third Feature is Snapshotting. Snapshotting provides a mechanism for creating a "frozen" copy of a volume at a single instant in time, without having to take that volume off-line. This is very useful for performing backups on a live system. Snapshots work with any volume (EVMS or compatibility), and can use any other available object as a backing store. After a snapshot is created, writes to the "original" volume cause the original contents of that location to be copied to the snapshot's storage object. Then, I/Os to the snapshot volume look like they come from the original at the time the snapshot was created.

File System Interface Modules

File System Interface Modules, or FSIMs, are the one layer of EVMS that only exists in the user-space engine. These plug-ins are used to provide coordination with the filesystems during certain volume management operations. For instance, when expanding or shrinking a volume, the filesystem must also be expanded or shrunk to the appropriate size. Ordering in this example is also important; a filesystem cannot be expanded before the volume, and a volume cannot be shrunk before the filesystem. The FSIMs allow EVMS to ensure this coordination and ordering.

FSIMs also provide the ability to perform filesystem operations from one of the EVMS user interfaces. For instance, a user can make new filesystems and check existing filesystems by interacting with the FSIM.