Linked by Thom Holwerda on Fri 27th Jul 2007 22:32 UTC, submitted by liquidat
Thread beginning with comment 258882
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.




Member since:
2005-07-08
For your gripes, you should check out EVMS.
My central complaint about all traditional UNIX-style logical volume managers is that they abstract a flat block device. The filesystem has no idea how to allocate physically-contiguous blocks. Block N and block N+1 can be on different disks and different controllers. Furthermore, mirroring is limited to the volume level, whereas filesystems and system administrators might want to have finer control of redundancy. Volumes have nominal sizes and don't efficiently use available capacity.
Modern filesystems are all moving toward extents, and so the volume manager should follow suit. Allocating a physically-contiguous extent should be like using malloc with a pluggable strategy function. Each extent descriptor should have a set of properties for the LVM and a pluggable set of properties for the filesystem. Instead of seeing a bunch of blocks, the filesystem owns a bunch of extents and can allocate more as quotas permit.
Basically, this is a heap for persistent storage. A volume has quotas instead of a size. Volumes allocate from the same pool of physical storage. Filesystems can specify allocation strategies, and they can have their own structures within extents. The storage layer can stripe and/or mirror extents as the filesystem/user sees fit. Extents can have checksums.
This allows the filesystem developer to work at a higher level while maintaining full control of how they organize their structures and data. It also allows more natural management of storage resources and volumes. Finally, it's more scalable to large disk arrays and distributed storage architectures.