Why? The FS will see a linear collention of block's it will never see
any holes with a LVM. The LVM will take care of the baping of logical
block addresses to disk block addresses.
A block-device LVM can do this, but at the cost of being very
inefficient when you need retire a physical device which happens to be
located in the middle of a filesystem, a lot more block copying needs to
be done than if you let the filesystem simply handle it.
> That's right. Build it into an LVM and it still won't be there for
> other filesystems to use. Doing resizing in the filesystem is
> sufficiently hard that having LVM interaction or not makes almost no
> difference to complexity.
It does not have to interact with the LVM except to know that the
total number of blocks in the LV has increased or decreased. Where as
if the file system is dealing directly with a collection of block
devices it must know exactly what group of physical blocks was
add/removed and must deal whit what to with Inodes that are in the
set of blocks. With the LVM all it has to do is add/remove data
segments from the END of the FS.
Adding and removing data segments from the end is just as hard as
removing data from the beginning of the filesystem. That's because the
data blocks and inode blocks are scattered across all available space,
for performance reasons (you want to keep files contiguous whenever
possible, so you allocate them in different block groups across the
filesystems; and you want inodes to be located close to their data
blocks, so the inode table is scattered across the filesystem as well).
Hence, removing and adding data blocks from the END of the FS is just as
difficult as removing and adding datablocks from the *MIDDLE* of the
filesystem.
Furthermore, keeping track of the block devices is really trivial;
that's not hard --- especially if you don't take a partition or a disk
device a chop it up in a Cuisinart into 4MB pieces. That's something
for which I just don't see the point. It makes it easier to handle
resizing the relative sizes of /var and /usr, say, but there are other
ways of handling that problem.
Part of the confusion appears to be coming from the fact that a number
of people are familiar with how AIX did things, and have been convinced
that it's the only way in the world to implement things. Well, it's
not. For example, the Digital Unix's Advanced Filesystem handled things
solely within the filesystem layer. In my mind at least, it's a much
cleaner solution.
That being said, even if we implement support for multiple block devices
in ext2, there's no reason why people can't use Heinz's LVM manager if
they think it adds value. The whole point of the bazaar model is that
we may have multiple ways of doing things --- after all, we already have
overlap in the MD devices and Heinz's LVM.
In the end, we can let the market decide; if they really want to do
things in the block device, it won't matter that Stephen and I and
others think it's a bad idea. It's not like we're going to storm into
people's systems and tell them they can't use it. By the same token, if
it turns out that advfs's (in Digital Unix) way of handling things is
superior, people will very quickly figure this out by themselves ---
despite what everyone who is in love with AIX might think.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu