346 lines
7.8 KiB
HTML
346 lines
7.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||
<HTML
|
||
><HEAD
|
||
><TITLE
|
||
>Plug-in layer definitions</TITLE
|
||
><META
|
||
NAME="GENERATOR"
|
||
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
||
REL="HOME"
|
||
TITLE="EVMS User Guide"
|
||
HREF="index.html"><LINK
|
||
REL="UP"
|
||
TITLE="What is EVMS?"
|
||
HREF="intro.html"><LINK
|
||
REL="PREVIOUS"
|
||
TITLE="What makes EVMS so flexible?"
|
||
HREF="x262.html"><LINK
|
||
REL="NEXT"
|
||
TITLE="Using the EVMS interfaces"
|
||
HREF="evmscmuse.html"></HEAD
|
||
><BODY
|
||
CLASS="sect1"
|
||
BGCOLOR="#FFFFFF"
|
||
TEXT="#000000"
|
||
LINK="#0000FF"
|
||
VLINK="#840084"
|
||
ALINK="#0000FF"
|
||
><DIV
|
||
CLASS="NAVHEADER"
|
||
><TABLE
|
||
SUMMARY="Header navigation table"
|
||
WIDTH="100%"
|
||
BORDER="0"
|
||
CELLPADDING="0"
|
||
CELLSPACING="0"
|
||
><TR
|
||
><TH
|
||
COLSPAN="3"
|
||
ALIGN="center"
|
||
>EVMS User Guide</TH
|
||
></TR
|
||
><TR
|
||
><TD
|
||
WIDTH="10%"
|
||
ALIGN="left"
|
||
VALIGN="bottom"
|
||
><A
|
||
HREF="x262.html"
|
||
ACCESSKEY="P"
|
||
>Prev</A
|
||
></TD
|
||
><TD
|
||
WIDTH="80%"
|
||
ALIGN="center"
|
||
VALIGN="bottom"
|
||
>Chapter 1. What is EVMS?</TD
|
||
><TD
|
||
WIDTH="10%"
|
||
ALIGN="right"
|
||
VALIGN="bottom"
|
||
><A
|
||
HREF="evmscmuse.html"
|
||
ACCESSKEY="N"
|
||
>Next</A
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
><HR
|
||
ALIGN="LEFT"
|
||
WIDTH="100%"></DIV
|
||
><DIV
|
||
CLASS="sect1"
|
||
><H1
|
||
CLASS="sect1"
|
||
><A
|
||
NAME="LAYERDEF"
|
||
></A
|
||
>1.5. Plug-in layer definitions</H1
|
||
><P
|
||
>EVMS defines a layered architecture where plug-ins in each layer
|
||
create abstractions of the layer or layers 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.</P
|
||
><P
|
||
></P
|
||
><DIV
|
||
CLASS="variablelist"
|
||
><DL
|
||
><DT
|
||
>Device managers</DT
|
||
><DD
|
||
><P
|
||
>The first (bottom) layer consists
|
||
of device managers.
|
||
These plug-ins communicate with hardware device drivers to
|
||
create the first EVMS objects. Currently, all devices are handled by a single plug-in.
|
||
Future releases of EVMS might need additional device managers
|
||
for network device management (for example, to manage
|
||
disks on a storage area network (SAN)).</P
|
||
></DD
|
||
><DT
|
||
>Segment managers</DT
|
||
><DD
|
||
><P
|
||
>The second layer consists of segment
|
||
managers. These plug-ins
|
||
handle the segmenting, or partitioning,
|
||
of disk drives. The Engine components can replace partitioning
|
||
programs, such as <B
|
||
CLASS="command"
|
||
>fdisk</B
|
||
> and
|
||
<SPAN
|
||
CLASS="application"
|
||
>Disk Druid</SPAN
|
||
>, and EVMS
|
||
uses Device Mapper to replace the in-kernel disk
|
||
partitioning code.
|
||
Segment managers can also be "stacked," meaning that
|
||
one segment manager
|
||
can take as input the output from another segment
|
||
manager.</P
|
||
><P
|
||
> EVMS provides the following segment managers:
|
||
DOS, GPT, System/390<39> (S/390), Cluster, BSD,
|
||
Mac, and BBR. Other segment manager
|
||
plug-ins can be added to support other
|
||
partitioning schemes.</P
|
||
></DD
|
||
><DT
|
||
>Region managers</DT
|
||
><DD
|
||
><P
|
||
>The third layer consists of region
|
||
managers.
|
||
This layer provides a place for plug-ins that ensure
|
||
compatibility with existing volume management schemes
|
||
in Linux and other operating systems.
|
||
Region managers are intended to model systems that
|
||
provide a logical abstraction above disks
|
||
or partitions.</P
|
||
><P
|
||
>Like segment managers, region managers can
|
||
also be stacked.
|
||
Therefore, the input object(s) to a region manager can
|
||
be disks, segments, or other regions.</P
|
||
><P
|
||
>There are currently three region manager plug-ins in EVMS:
|
||
Linux LVM, LVM2, and Multi-Disk (MD).
|
||
<P
|
||
></P
|
||
><DIV
|
||
CLASS="variablelist"
|
||
><DL
|
||
><DT
|
||
>Linux LVM</DT
|
||
><DD
|
||
><P
|
||
>The Linux LVM plug-in provides compatibility with
|
||
the Linux LVM and allows the creation of volume groups
|
||
(known in EVMS as containers) and logical volumes
|
||
(known in EVMS as regions). </P
|
||
></DD
|
||
><DT
|
||
>LVM2</DT
|
||
><DD
|
||
><P
|
||
> The LVM2 plug-in provides compatibility with the
|
||
new volume format introduced by the LVM2 tools from Red Hat. This plug-in
|
||
is very similar in functionality to the LVM plug-in. The primary difference
|
||
is the new, improved metadata format.
|
||
</P
|
||
></DD
|
||
><DT
|
||
>MD</DT
|
||
><DD
|
||
><P
|
||
>The Multi-Disk (MD) plug-in for RAID provides
|
||
RAID levels linear, 0, 1, 4, and 5 in
|
||
software. MD is one plug-in that displays as four region
|
||
managers that you can choose from.</P
|
||
></DD
|
||
></DL
|
||
></DIV
|
||
></P
|
||
></DD
|
||
><DT
|
||
>EVMS features</DT
|
||
><DD
|
||
><P
|
||
>The next layer consists of 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.
|
||
All EVMS features 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: drive linking, Bad
|
||
Block Relocation, and snapshotting. </P
|
||
><P
|
||
></P
|
||
><DIV
|
||
CLASS="variablelist"
|
||
><DL
|
||
><DT
|
||
>Drive Linking</DT
|
||
><DD
|
||
><P
|
||
>Drive linking allows any
|
||
number of objects to be linearly concatenated together into a
|
||
single object. A drive linked volume can be expanded by
|
||
adding another storage object to the end or shrunk by removing the last object.</P
|
||
></DD
|
||
><DT
|
||
>Bad Block Relocation</DT
|
||
><DD
|
||
><P
|
||
>Bad Block Relocation (BBR)
|
||
monitors its I/O path and detects write failures (which can 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. Additional I/Os to that
|
||
location are redirected to the new location.</P
|
||
></DD
|
||
><DT
|
||
>Snapshotting</DT
|
||
><DD
|
||
><P
|
||
>The Snapshotting feature 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 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 and made into an EVMS volume, writes to the "original" volume cause the
|
||
original contents of that location to be copied to the snapshot's
|
||
storage object. Reads to the snapshot volume look like they
|
||
come from the original at the time the snapshot was created.
|
||
</P
|
||
></DD
|
||
></DL
|
||
></DIV
|
||
></DD
|
||
><DT
|
||
>File System Interface Modules</DT
|
||
><DD
|
||
><P
|
||
>File System Interface Modules (FSIMs)
|
||
provide coordination with the
|
||
file systems during certain volume management
|
||
operations. For
|
||
instance, when expanding or shrinking a volume,
|
||
the file system
|
||
must also be expanded or shrunk to the appropriate size.
|
||
Ordering in this example is also important;
|
||
a file system cannot
|
||
be expanded before the volume, and a volume cannot
|
||
be shrunk before the file system.
|
||
The FSIMs allow EVMS to ensure this
|
||
coordination and ordering.</P
|
||
><P
|
||
>FSIMs also perform file system
|
||
operations from one of the EVMS user interfaces. For instance,
|
||
a user can make new file systems and check existing file systems
|
||
by interacting with the FSIM.</P
|
||
></DD
|
||
><DT
|
||
>Cluster Manager Interface Modules</DT
|
||
><DD
|
||
><P
|
||
>Cluster Manager Interface Modules, also
|
||
known as the EVMS Clustered Engine (ECE), interface
|
||
with the local cluster manager installed on the system.
|
||
The ECE provides a standardized ECE API to the Engine
|
||
while hiding cluster manager details from the Engine.</P
|
||
></DD
|
||
></DL
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="NAVFOOTER"
|
||
><HR
|
||
ALIGN="LEFT"
|
||
WIDTH="100%"><TABLE
|
||
SUMMARY="Footer navigation table"
|
||
WIDTH="100%"
|
||
BORDER="0"
|
||
CELLPADDING="0"
|
||
CELLSPACING="0"
|
||
><TR
|
||
><TD
|
||
WIDTH="33%"
|
||
ALIGN="left"
|
||
VALIGN="top"
|
||
><A
|
||
HREF="x262.html"
|
||
ACCESSKEY="P"
|
||
>Prev</A
|
||
></TD
|
||
><TD
|
||
WIDTH="34%"
|
||
ALIGN="center"
|
||
VALIGN="top"
|
||
><A
|
||
HREF="index.html"
|
||
ACCESSKEY="H"
|
||
>Home</A
|
||
></TD
|
||
><TD
|
||
WIDTH="33%"
|
||
ALIGN="right"
|
||
VALIGN="top"
|
||
><A
|
||
HREF="evmscmuse.html"
|
||
ACCESSKEY="N"
|
||
>Next</A
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
WIDTH="33%"
|
||
ALIGN="left"
|
||
VALIGN="top"
|
||
>What makes EVMS so flexible?</TD
|
||
><TD
|
||
WIDTH="34%"
|
||
ALIGN="center"
|
||
VALIGN="top"
|
||
><A
|
||
HREF="intro.html"
|
||
ACCESSKEY="U"
|
||
>Up</A
|
||
></TD
|
||
><TD
|
||
WIDTH="33%"
|
||
ALIGN="right"
|
||
VALIGN="top"
|
||
>Using the EVMS interfaces</TD
|
||
></TR
|
||
></TABLE
|
||
></DIV
|
||
></BODY
|
||
></HTML
|
||
> |