Booting - Enterprise Volume Management System

[Alan Mckinnon]

On Fri, 2006-08-11 at 12:26 +0100, Toby Kelsey wrote:

> > unmount? Have you actually read the howto?
> 
> Perhaps you should try reading it.
> 
> "  ext2/ext3
> 
> Unless you have patched your kernel with the ext2online patch it is necessary to 
> unmount the file system before resizing it."

Come on Toby, you're beating a dead horse here. It doesn't matter
whether you use EVMS, LVM or nothing, if you have to umount a file
system to adjust it, then you have to umount it to adjust it. It's got
nothing to do with LVM and everything to do with file systems.

> Reiserfs, xfs and jfs can be grown mounted, but reiserfs is slower and allegedly 
> buggier than other filesystems, and xfs and jfs are unsuitable for LVM as I have 
> mentioned already.

Hmm. Allegedly. Statement not backed up with evidence and facts.  'nuff
said.

> >>- with the main disadvantage of one big partition -  
> >>allowing fs corruption and installers to affect user and system data together. 
> > 
> > 
> > What are you talking about?
> 
> You don't think there are any disadvantages of one big partition?  Why even 
> bother with LVM on a single disk if you can just make one big partition?

Let's see:

- A partition is as big as it needs to be and no bigger.
- Runaway processes can't fill the filesystem, leaving you in a tricky
state. For an amazing example of how big a pita this is, try fix a
windows machine when exchange fills the file system.
- different mount options per filesystem
- quotas, differing per filesystem
- selecting the correct filesystem type on a per-directory basis.
Perhaps ext3 is suitable for your /usr, but you have to travel far to
beat reiser on /var 
- a corrupt file system doesn't bring down the entire machine, only that partition.

I don't think you know too much about filesystems, partitions and the
effect corruption has. A corrupt area on the disk affects only the *file
system* using it, not the partition it's on. 

> >>The main advantage appears being able to resize logical volumes and filesystems 
> >>easily, but for jfs "this is extremely error prone"

Says who?

> > How so? mount -o remount,resize /your/jfs
> 
> Perhas you know better than the HOWTO:
> 
> "Known Kernel Bug
> 
> Some kernel versions have problems with this syntax (2.6.0 is known to have this 
> problem). 

2.6.0 is also 24 months out of date.... and was a pre-alpha at the best
of times anyway. Who is using it on a production machine?

> In this case you have to explicitly specify the new size of the 
> filesystem in blocks. This is extremely error prone as you must know the 
> blocksize of your filesystem and calculate the new size based on those units. "
> 
> Until "some kernels" are identified or fixed it is not safe.  I am not going to 
> continue pasting blocks of text from the HOWTO every time you profess ignorance. 
>   Please read it.

So which kernels exactly are affected? Or are you getting all nervous
now because you read that there might possibly be a problem? If you
never read that howto making those claims you would not be worried, yet
it wouldn;t change the status of the bug one little bit. Think about
that.

> >>and even for ext2/3 "there  
> >>is currently no e2fsadm equivalent for LVM 2
> > 
> > 
> > True, but ext3 can be made larger online, AFAIK. I don't use ext3, though.
> 
> With a kernel patch which is judged "rather dangereous" as I already said.
> If you only use reiserfs anyway then LVM is more useful.

"Rather dangerous" according to who exactly? And does this person have
any credibility at all? 

> >>Since you cannot shrink xfs and jfs the main functionality becomes  
> >>useless for many advanced users.

Not true. You still can't shrink xfs or jfs if you don't use LVM, so
your argument is useless. You are proving something that is irrelevant.

> > Wrong. Mostly, filesystems will grow. It's, in my experience, quite
> > rare, that filesystems need to be made smaller.
> 
> You can grow and move partitions with parted anyway, so LVM has no advantage if 
> that's what you restrict it to.  

You can't move them easily on a full disk, and the process mostly always
involves moving partitions around in chunks - an error-prone affair at
best.

What LVM _REALLY_ does, is this:

It removes the need for a filesystem to reside on a *contiguous*
physical disk partition. You manipulate a virtual partition and don't
worry about the underlying physical disk structure

> Of course you can also use LVM with multiple 
> disks, and it has a genuine advantage there.  I suspect it is not as fast as 
> using specific software or hardware RAID though, and the HOWTO says striping 
> with LVM can actually reduce performance if you have more than one LV per disk.

Software raid will always be slower than LVM, and LVM itself is very
fast - it's really nothing more than a simple lookup to find which
physical sector corresponds to the part of the file system in use. The
filesystem is already doing very many of those sort of lookups anyway,
and this one extra very fast operation hurts relatively little

> >>While it may be useful for servers, with confidence-building statements like "it 
> >>seems that the online resizing patch is rather dangerous" I would suggest it is 
> >>not yet suitable for a home or laptop system.
> > 
> > 
> > Wrong. On what experience do you base your conclusion? On your false reading?
> 
> Based on the HOWTO.  Please read it.

I read the HOWTO. I am not impressed. Many assertions. Few facts.

> LVM has its place if you know what you are doing (and have multiple disks with 
> partitions which grow and never shrink), but the "LVM is good for everybody, 
> even laptop users" rhetoric I responded to was OTT.

LVM really really really is good for everyone. The same way that file
systems and the journals on them are good for everyone, or a multi-user
kernel is good for everyone even if you only run as one user at a time.
It's well proven, reliable, stable, has few if any downsides and when
you need it you are very glad you've got it.

alan