Isn't this (and the filesystem/device mapping) where the LVM comes in?
If you create an LVM device to map multiple physical devices onto one
logical LVM device, with a sparse 64-bit block space, then adding and
subtracting drives becomes fairly trivial. Of course, you need a
filesystem that's aware of the LVM's mappings, and can cope with a
sparse block space. Unfortunately, this makes the LVM fairly useless
for the ext2fs.
>Given that disks will be inserted at arbitrary places in the global
>block numbering name space, how do you record this information? Because
>if the system shuts down and comes back up, the information about where
>in the multi-disk volume is very important.
That's a bit tricky. Add a header to each LV partition. Assign each
LV volume a universally unique ID, and give each partition in the LV
its own UUID and put the LV and partition UUIDs in the partition
header. Now all you need is a partition UUID<->block offset mapping.
For small LVs, you can store the complete mapping in the header. For
larger LVs, you can let each partition keep track of a subset of the
mappings (2 forward, 2 back, perhaps). When you reboot, a quick scan
of all partitions on all drives will correctly identify which are
involved in LVs, and the UUIDs should be enough to recreate the
complete LV layout.
Alternately, we could use a user-mode LV manager (call it lvmount)
that reads a configuration file from /etc, but dynamic SCSI devices
make this dangerous.
Scott