> Hi,
>
> On Mon, 22 Jun 1998 18:26:30 -0600 (MDT), Colin Plumb <colin@nyx.net>
> said:
>
> > Building a fake device out of bits of real devices is not that complicated.
> > The RAID code does this and the file system doesn't even need to know about
> > it.
>
> > The tricky part comes when you want to add or remove real devices, because
> > then your fake device changes size, and the file system needs to know
> > about *that*.
Well, if you try to *shrink* the logical volume smaller than the FS, it
should fail, the LVM should be aware of what is used. In this case, you
would have to first add a pv, move the old pv's contents to the old one,
and THEN remove it.If you *grow* the volume, you should have to *grow* the
FS. I think it is NOT the job of the FS to be "aware" of all LVM
activity. Use ext3resize, ext3defrag, etc... When there is a ext3defrag I
assume its main purpose would be to have the ability to move data away
from the end of an fs to be able to shrink the FS, then the LV. Simplify
things?
> Correct. There is in fact so much filesystem interaction required that
> I'm not at all convinced that a block-device LVM is needed or even
> useful.
Don't give up! Most of the FS facilities that are really needed are being
developed or at least talked about. Like you said, it's this LVM
"awareness" that has awk'ed things up.
> Virtual disks for redundancy or performance are just fine, but
> when it comes to filesystem sizing, the fs has to be actively involved
> in any change. Given that, we can actually implement the whole thing in
Absolutely, BUT if you use the Veritas model, LVM provides the logical
volume. The FS, whether it be HPUX's vxfs, Sun's fs, whatever it is is
responsible for providing manual resizing and defragging. The
FS tools do that. The LVM just decides whether it can perform the
operation requested given the alocation status of the LV. It will know,
because when you mk???fs on it, unlike a "partition", it knows how much of
it is alocated. Another LVM nicity.
> the filesystem.
>
> Miguel's prototype LVM stuff works by letting you mke2fs a new partition
> and then daisy-chain that new device on to the end of the existing
> filesystem, at run time, while it is all mounted. Removing such a
> partition from the middle of a logical volume set is harder but
> certainly feasible in theory. Is there really any overwhelming
> justification for needing extra device-level support for this
> functionality?
Acutally, yes. His implementation provides us not with a vanilla block
device, but with a logical volume that is extent based, and one that has
definable properties beyond the capability of any normal block device.
With this implementation, you are not limited by BIOS partitions... I
might liken it to a BSD disklabel, but that doesn't come close to
explaining the advantages... All VG's can have allocation policies, like
only contiguous, or a loose "who cares" policy. Also, you are not limited
by BIOS partitions... Oh, did I mention you are not limited by BIOS
partitions? Have you used LVM before? Get to a machine that has the
Veritas LVM, and play with the [lp]vdisplay and vgdisplay cmds.
> Given that we _need_ filesystem support, my own reaction
> is that splitting the support between fs and block device just
> complicates the matter; it's better just to do it in one place.
You can use LVM with the existing ext2, you just can't resize ext2fs.
This is the only thing needed in my limited view. Please understand, I
know LVM, but I do not claim to be an expert on the interaction of the fs
and simple block devices. I wouldn't call an LV a simple block device,
though.
-Shawn
> --Stephen
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu