> Basically the way it works is that the metadevice driver gets fed a
> configuration of which physical devices it should use and how it
> should lay them out to form virtual block devices. Now, the
> metadevice driver creates the virtual block devices and registers
> them with the block device layer.
> Now one can implement many types of disk configurations, concatenated
> disks, striped disks, concatenated stripes, concatenated raids,
> striped concatenations, whatever.
We already have something similar to this: The Multiple devices
driver is responsible for handling these situations. My proposal is
more of the kind of modifications that are required to the file system
so that it can handle the availability of more blocks/block groups in
The MD layer can take care of the configurations you mentioned:
concatenated, stripped and the mirrored case (just like IRIX does
> We can probably do logging filesystems with good extensions to the
> block device stuff, though I think that there may be some problems
> with prioritizing writes in the buffer cache for the log info.
There are two possible approachs to do logging: make a complete new
log structured file system in the spirit of Sprite's logfs, or just
extend the ext2fs to do logging of the metadata. The first case is
not in the range of time I am trying to spend, while the kernel
requirements for the latter have been outlined by Ted in his previous
post (maybe the post just went to the enh-fs mailing list though).