> 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.
No... No no no no no... An LV is a device that will grow/shrink
transparently to the FS. If it shrinks, the FS must not have allocated
the extents to be removed, and if it grows, you must explicitely grow the
FS, and it will have grown at the END!!!!!!!. The addition of differing
numbers of extents in the middle of an LV breaks the abstraction and is,
therefore, not desirable. All resources given to anything on the system
by the LVM will be simple, and things will be transparent. It will look
like any other device. There are rules regarding growing/shrinking that
make it trivial for an FS to support it. The LVM will NOT NOT NOT NOT
require an FS to get with the program and stretch itself because the begin
and end points of where an FS was have etra blocks in the middle because
some bonehead added a 3 gig PV where a 2 gig was in the middle.
> 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.
Sheesh, I'll leave this to someone else...
-Shawn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu