![]() | |||||||||||||
Messages in this thread |
mingo writes: > On Wed, 24 Jun 1998, Stephen C. Tweedie wrote: >> ... 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 | ||||||||||||
| Last update: 2005-03-22 12:43 [W:0.264 / U:0.120 seconds] ©2003-2008 Jasper Spaans | |||||||||||||