Vinum's manpage makes my head spin. I was wondering if anyone had considered implementing something a bit more straightforward and also more dynamic. Suppose you: (1) Divide all your disks up-front into equal sized chunks, say 4MB. (2) Use an indirection table to map each volume into an arbitary set of these chunks across all available disks. (3) Store the indirection table at the end of a partition, as other GEOM modules do for their metadata, and cache it in RAM. (e.g. a 160GB drive, divided into 4MB blocks, each of which has a 32-bit indirection table entry, would require only 160KB of indirection table) Why do this? - You can install a system with minimal /, /usr, /var and /home, and then grow each one in small increments as needed just by adding spare chunks. With vinum you would end up with an increasingly complex configuration with more and more subdisks, since each subdisk must be a contiguous range of a physical drive. If you decide to get rid of a volume, then you need to keep track of those subdisk fragments. I'm not sure if it's possible to take an unused subdisk and split it so you can assign part of the free space to another volume. Even if you can, this still means more subdisk fragmentation. With the above scheme an unused volume just returns its chunks into the pool for reallocation. - You can identify 'hot' chunks and move them between disks. This is a lot more flexible than fixed striping. Unlike striping, it could distribute load between unevenly matched devices (e.g. 10GB on one disk and 20GB on another). It could also migrate 'hot' data to faster devices, such as a battery-backed RAM disk[*]. With the right tools, this could all happen automatically. - Mapping volumes in fixed chunks in this way lends itself well to visualisation, e.g. all chunks belonging to the same volume can be shown as blocks in the same colour. - What I'm suggesting may or may not look like Linux's LVM; I've never used that. If its data structure is suitable, we can just use that and gain some compatibility for multi-boot systems. I guess you could work this way in vinum, dividing all your storage up front into 4MB subdisks, but it doesn't sound like fun to me. I also guess there's a lot of devil-in-the-details to do with marking a volume as 'up' or 'down'; but hopefully mirroring and RAID could be delegated to other GEOM modules, leaving us just with logical {volume,extent} to physical {drive,extent} mapping to do. Has something like this been proposed, discussed and/or discarded before? Thanks, Brian. [*] e.g. http://uk.giga-byte.com/Peripherals/Products/Products_i-RAM%20(Rev%201.1).htmReceived on Fri Nov 18 2005 - 10:43:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC