>> ... and fs resizing on Linux will need fs support too. Again, the
>> question is, given that the fs needs to add support, do we need resizing
>> support at the block device layer TOO? Or is that just extra
>> unnecessary complexity? I for one would be quite happy with a scheme in
>> which the filesystem could span multiple block devices; that would allow
>> shrinking and growing at will, without any complex interaction
>> requirements between the filesystem and the block device layers.
>
> i think much of the conceptual complexity here comes from the fact that we
> use PC style partitions, and do not have clear distinctions between these
> 'legacy storage units' and higher level storage concepts. We have 'simple
> MSDOS partitions', 'striped partitions', maybe 'LVM managed partitions',
> and the concept line gets blurred.
How about this:
An LVM is a deamon that can describe (to tools & kernel) a LV.
That data is stored in a daemon-specific way, such as /etc/foo.
An LVM-aware filesystem directly uses multiple devices, but only
as instructed by the daemon. Those devices may be any mix of
PC partitions, RAID devices, and whole disks. Sub-partition space
allocation can be done by the deamon creating md devices.
There are devices in /dev that represent the LV for /proc/mounts,
but such devices do not contain actual data. These LV devices remove
the need for a master-slave type of system. Admin tools work by
ioctls on the LV device and/or a network connection to the LVM daemon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu