Партнёры:
Хостинг:
GEOM - modular disk I/O request transformation framework
Transformations in a 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'' differs from most and in some cases all previous implementations in the following ways:
Being extensible means that new transformations are treated no differently 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. 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.
A ``class'' represented by the data structure Vt 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 Vt g_geom . In a typical i386 Fx system, there will be one geom of class MBR for each disk.
A ``provider'' represented by the data structure Vt g_provider , is the front gate at which a geom offers service. A provider is Do a disk-like thing which appears in /dev Dc - 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:
All geoms have a rank-number assigned, which is used to detect and prevent loops in the acyclic directed graph. This rank number is assigned as follows:
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 , but the sensible set of options are:
When a geom orphans a provider, all future I/O requests will ``bounce'' on the provider with an error code set by the geom. Any consumers attached to the provider will receive notification about the orphanization when the event loop gets around to it, and they can take appropriate action at that time.
A geom which came into being as a result of a normal taste operation should self-destruct unless it has a way to keep functioning whilst lacking the orphaned provider. Geoms like disk slicers should therefore self-destruct whereas RAID5 or mirror geoms will be able to continue as long as they do not lose quorum.
When a provider is orphaned, this does not necessarily result in any immediate change in the topology: any attached consumers are still attached, any opened paths are still open, any outstanding I/O requests are still outstanding.
The typical scenario is:
While this approach seems byzantine, it does provide the maximum flexibility and robustness in handling disappearing devices.
The one absolutely crucial detail to be aware of is that if the device driver does not return all I/O requests, the tree will not unravel.
Imagine a disk, da0 on top of which an MBR geom provides da0s1 and da0s2 and on top of da0s1 a BSD geom provides da0s1a through da0s1e and that both the MBR and BSD geoms have autoconfigured based on data structures on the disk media. Now imagine the case where da0 is opened for writing and those data structures are modified or overwritten: now the geoms would be operating on stale metadata unless some notification system can inform them otherwise.
To avoid this situation, when the open of da0 for write happens, all attached consumers are told about this and geoms like MBR and BSD will self-destruct as a result. When da0 is closed, it will be offered for tasting again and, if the data structures for MBR and BSD are still there, new geoms will instantiate themselves anew.
Now for the fine print:
If any of the paths through the MBR or BSD module were open, they would have opened downwards with an exclusive bit thus rendering it impossible to open da0 for writing in that case. Conversely, the requested exclusive bit would render it impossible to open a path through the MBR geom while da0 is open for writing.
From this it also follows that changing the size of open geoms can only be done with their cooperation.
Finally: the spoiling only happens when the write count goes from zero to non-zero and the retasting happens only when the write count goes from non-zero to zero.
To understand the utility of this, imagine a provider being mounted as a file system. Between the DEVFS geom's consumer and its provider we insert a mirror module which configures itself with one mirror copy and consequently is transparent to the I/O requests on the path. We can now configure yet a mirror copy on the mirror geom, request a synchronization, and finally drop the first mirror copy. We have now, in essence, moved a mounted file system from one disk to another while it was being used. At this point the mirror geom can be deleted from the path again; it has served its purpose.
Finally, I/O is the reason we even do this: it concerns itself with sending I/O requests through the graph.
In total, four different I/O requests exist in : read, write, delete, and ``get attribute.''
Read and write are self explanatory.
Delete indicates that a certain range of data is no longer used and that it can be erased or freed as the underlying technology supports. Technologies like flash adaptation layers can arrange to erase the relevant blocks before they will become reassigned and cryptographic devices may want to fill random bits into the range to reduce the amount of data available for attack.
It is important to recognize that a delete indication is not a request and consequently there is no guarantee that the data actually will be erased or made unavailable unless guaranteed by specific geoms in the graph. If ``secure delete'' semantics are required, a geom should be pushed which converts delete indications into (a sequence of) write requests.
``Get attribute'' supports inspection and manipulation of out-of-band attributes on a particular provider or path. Attributes are named by ASCII strings and they will be discussed in a separate section below.
(Stay tuned while the author rests his brain and fingers: more to come.)
The first precursor for was a gruesome hack to Minix 1.2 and was never distributed. An earlier attempt to implement a less general scheme in Fx never succeeded.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |