NAMEGEOM - modular disk I/O request transformation framework
DESCRIPTIONThe GEOM framework provides an infrastructure in which ''classes'' can perform 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 displacement performed in typical disk partitioning modules over RAID algorithms and device multipath resolution to full blown cryptographic protection of the stored data. Compared to traditional ''volume management'', GEOM differs from most and in some cases all previous implementations in the following ways: +
TERMINOLOGY AND TOPOLOGYGEOM is quite object oriented and consequently the terminology borrows a lot of context and semantics from the OO vocabulary: A ''class'', represented by the data structure g_class implements one particular kind of transformation. Typical examples are MBR disk partition, BSD disklabel, and RAID5 classes. An instance of a class is called a ''geom'' and represented by the data structure g_geom. In a typical i386 FreeBSD system, there will be one geom of class MBR for each disk. A ''provider'', represented by the data structure g_provider, is the front gate at which a geom offers service. A provider is ''a disk-like thing which appears in /dev'' - a logical disk in other words. All providers have three main properties: ''name'', ''sectorsize'' and ''size''. A ''consumer'' is the backdoor through which a geom connects to another geom provider and through which I/O requests are sent. The topological relationship between these entities are as follows: +
SPECIAL TOPOLOGICAL MANEUVERSIn addition to the straightforward attach, which attaches a consumer to a provider, and detach, which breaks the bond, a number of special topological maneuvers exists to facilitate configuration and to improve the overall flexibility. TASTING is a process that happens whenever a new class or new provider is created, and it provides the class a chance to automatically configure an instance on providers which it recognizes as its own. A typical example is the MBR disk-partition class which will look for the MBR table in the first sector and, if found and validated, will instantiate a geom to multiplex according to the contents of the MBR. A new class will be offered to all existing providers in turn and a new provider will be offered to all classes in turn. Exactly what a class does to recognize if it should accept the offered provider is not defined by GEOM, but the sensible set of options are: +
DIAGNOSTICSSeveral flags are provided for tracing GEOM operations and unlocking protection mechanisms via the kern.geom.debugflags sysctl. All of these flags are off by default, and great care should be taken in turning them on. 0x01 (G_T_TOPOLOGY) Provide tracing of topology change events. 0x02 (G_T_BIO) Provide tracing of buffer I/O requests. 0x04 (G_T_ACCESS) Provide tracing of access check controls. 0x08 (unused) 0x10 (allow foot shooting) Allow writing to Rank 1 providers. This would, for example, allow the super-user to overwrite the MBR on the root disk or write random sectors elsewhere to a mounted disk. The implications are obvious. 0x40 (G_F_DISKIOCTL) This is unused at this time. 0x80 (G_F_CTLDUMP) Dump contents of gctl requests.
SEE ALSOlibgeom(3), disk(9), DECLARE_GEOM_CLASS(9), g_access(9), g_attach(9), g_bio(9), g_consumer(9), g_data(9), g_event(9), g_geom(9), g_provider(9), g_provider_by_name(9)
HISTORYThis software was developed for the FreeBSD Project by Poul-Henning Kamp and NAI Labs, the Security Research Division of Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 (''CBOSS''), as part of the DARPA CHATS research program. The first precursor for GEOM was a gruesome hack to Minix 1.2 and was never distributed. An earlier attempt to implement a less general scheme in FreeBSD never succeeded.
AUTHORSPoul-Henning Kamp <phk@FreeBSD.org> GEOM(4)