Geom

Latest revision as of 07:07, 3 January 2009

    The GEOM framework provides an infrastructure in which "classes" can per-
    form transformations on disk I/O requests on their path from the upper
    kernel to the device drivers and back.

    Transformations in a GEOM context range from the simple geometric dis-
    placement performed in typical disk partitioning modules over RAID algo-
    rithms and device multipath resolution to full blown cryptographic pro-
    tection of the stored data.

    Compared to traditional "volume management", GEOM differs from most and
    in some cases all previous implementations in the following ways:

    o   GEOM is extensible.  It is trivially simple to write a new class of
        transformation and it will not be given stepchild treatment.  If
        someone for some reason wanted to mount IBM MVS diskpacks, a class
        recognizing and configuring their VTOC information would be a trivial
        matter.

    o   GEOM is topologically agnostic.  Most volume management implementa-
        tions have very strict notions of how classes can fit together, very
        often one fixed hierarchy is provided for instance subdisk - plex -
        volume.

    Being extensible means that new transformations are treated no differ-
    ently than existing transformations.

    Fixed hierarchies are bad because they make it impossible to express the
    intent efficiently.  In the fixed hierarchy above it is not possible to
    mirror two physical disks and then partition the mirror into subdisks,
    instead one is forced to make subdisks on the physical volumes and to
    mirror these two and two resulting in a much more complex configuration.
    GEOM on the other hand does not care in which order things are done, the
    only restriction is that cycles in the graph will not be allowed.