Booting - Enterprise Volume Management System

[Toby Kelsey]

Alan Mckinnon wrote:
> 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.

But if a big advantage of LVM is that you don't have to unmount to adjust
partitions, then this is negated isn't it?

>>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.

reiserfs:
There were some review links posted recently which showed it came off badly.  If
resierfs works for you I not going to argue strongly agaist it.

xfs & jfs:
Since they can't be shrunk you lose LVM functionality.

>>>>- 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 agree, there are many problems with one big partition.  One big logical volume
also has a corruption risk.

> 
> 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.

I expect it's possible for corrupt metadata about the filesystem size to cause
writes to occur outside the filesystem, but that particular corruption is
probably rare.

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

The HOWTO <http://www.tldp.org/HOWTO/LVM-HOWTO/extendlv.html>, although 
Alexander claims this is outdated.

>>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.

Unknown bugs may always exist, does that mean we should ignore reports of known
bugs?  Are HOWTO authors likely to report problems if there are none?   This bug
mention is disappointingly vague about kernel versions, but that doesn't
discount it.

>>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? 

The HOWTO author is given as AJ Lewis <aj(at)terrascale.com>, and appears to
have worked for RedHat in 2005.  I suppose managing to author a HOWTO on the
topic gives him some credibility, but you may disagree.

>>>>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.

Suppose you buy a Ferrari [LVM] that can go 150 mph [online resizing], but you
only use it in a 30 mph zone [JFS/ext3].  Doesn't that cancel it's advantage
over a Fiat Uno [partitions], even if the Fiat is also restricted to 30 mph,
especially if the Ferrari is sold on its speed?

> 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

I agree. And to make the most use of it, you need filesystems that are fully
resizable while active.

> 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

I stand corrected. I would have thought that simple software striping would have
less overhead than LVM striping.

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

> 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.

If all the problems mentioned in the HOWTO have been fixed, then I would agree.

Toby