On Tue, Jun 23, 1998 at 11:40:56AM +0100, Stephen C. Tweedie wrote:
> 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*.
>
> 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. 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
> the filesystem.
I would not like to see a special ext2 implentation for resizing, holes,
that the ext2 cares on "physical devices" and reorganization of blocks.
The LVM approach with the "virtual block device" makes many things much easier.
You can keep filesystem code very simple, and the LVM code also isnt very
complex. The only thing you might take care on is the Block Allocation
of the LVM which you might do as complex and intelligent as you like
but a bug in there will NOT cause data to get lost or corrupt. The PEs
will just not be there where they should and it would be just an performance
/reliability problem which you might fix on the fly without any filesystem
interaction. Also creating a mirror, raid5, stripe of a simple filesystem on
the fly would be VERY easy, MUCH easier then doing it in the filesystem level.
I am sure i know how difficult it is to get a filesystem stable, but in my
eyes it would be better to have an stable ext2 which is NOT capable of
all features, and a filesystem which is resizeable and has some support
for all our nifty features we like (BTrees, resizing, journaling etc),
which might one day be stable as ext2.
I think a big approach is to bring down complexity, as this makes
things more unstable, and more difficult to bugfix, and the LVM is
an step to bring functionality/features to filesystems without
an big complexity increase.
> 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
This is still (i am sure) very difficult and not that easy as it
sounds here. And still - you tight bound to physical devices
(read: partitions, drives etc)
> 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? 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.
I dont think that this complicates the things. We only need some
interaction between filesystems and devices. Like the
filesystem telling the device "I would like you to shrink by 4 GB, tell me
if you are able to do this" "Could you please shrink now by 4 GB, tell me
when ready" ...
"Normal" partitions (read: block devices) will tell not to be able to shrink
and my filesystem tools (userspace) will tell me to be unable to shrink this.
If able, they will shrink the filesystem and the filesystem will tell the device
to be shrunk and the device will do this also. The other way round
it will be the same.
The growing and shrinking of devices will go from the top to the bottom
not the other way round e.g. filesystem->LVM->device. Reorganization of
PEs to devices and/or any Raid level are transparent to the overlying
filesystem so theres is no need to involve the filesystem, do it on the
fly, transparently to the filesystem.
BTW: I feel a bit like ext2 is going the Microsoft way of doing things. Keep
as much as compatibility as possible, and therefor accept compromises. This
has led Microsoft to installing a 32bit OS into an 16 Bit FAT partition. We do not have
the need for quick return-of-invest and commercial success, so we might
choose the BEST TECHNICAL SOLUTION, and we dont need to take
compromises.
Flo
-- Florian.Lohoff@mediaWays.net +49-5241-80-7085 aka flo@mini.gt.owl.de @HOME +49-5241-470566- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu