Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: (reiserfs) Re: LVM / Filesystems / High availability | Date | Thu, 25 Jun 1998 03:05:23 -0400 (EDT) |
| |
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
| |