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.