Booting - Enterprise Volume Management System

[Toby Kelsey]

Alexander Skwar wrote:
> Toby Kelsey <toby_kelsey at ntlworld.com>:

> As I said, ext3 can be resized online, as far as I know. I've also
> said, that I don't use ext3.

And as I have already said, it is considered dangerous to do so.  Repetition has
not improved your argument.

> In how far are XFS and JFS unsuitable? Because they can't be made
> smaller?
> 
> If so, then they are also unsuitable for old fashioned partitioning, by
> what you say.

Since the main LVM advantage is meant to be easy resizing, using JFS and XFS
negate that - except for growth into unused disk-space.  They also have that
disadvantage with old-fashioned partitioning as you note.

If you're going to keep large chunks of disk unallocated to allow LVM to work,
you could just as well use that space to copy or resize basic partitions.  It
seems to me that LVM is mainly advantageous when you have limited disk-space,
and in that case you need to be able to shrink as well as grow filesystems.

>>>>- 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?
> 
> 
> Yes, of course I do think so. Reason: You can't make specialized
> filesystems.

The most common partitioning request on this mailing-list is to move /home from
the root partition. Mainly so people can simplify backup processes, separate
user data from system data, allow safe reinstalls, and increase capacity by
upgrading drives.  I don't recall anyone asking to do it just so they can use a
different filesystem for /home.  Your requirements clearly differ.

>>"Known Kernel Bug
>>
>>Some kernel versions have problems with this syntax (2.6.0 is known to have this 
>>problem).
> 
> 
> This is *VERY* old. The current kernel is 2.6.17.7. Ubuntu ships 2.6.15.

Fine. So you know better than the HOWTO that no recent kernels are affected.

>>>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.
> 
> 
> I also use xfs and jfs and LVM is very useful. It's also useful with ext3.

Perhaps the HOWTO is incoreect and the patch isn't dangerous then.  Since you
know much better than the HOWTO perhaps you should update it.

>>>>Since you cannot shrink xfs and jfs the main functionality becomes  
>>>>useless for many advanced users.
>>>
>>>
>>>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,
> 
> 
> Oh, you can do that online? You don't have to take down close to everything?
> Since when does the kernel directly, ie. with no reboot, take notice of
> the new partition boundaries?

man partprobe

>>so LVM has no advantage if  
>>that's what you restrict it to.
> 
> 
> "that" == to what? making bigger?
> 
> You're wrong.
> 
> Suppose you've got hda5 up to hda10. Now you need to make hda5 bigger.
> 
> Much fun!
> 
> Or can this be done WITHOUT taking hda5, hda6, hda7, hda8, hda9 and hda10
> "offline" (ie. unmounting the file systems contained on those partitions)?

I don't claim you never have to unmount, but with LVM you have to unmount with
ext3 which is the common case.  If as you say online resizing is completely safe
then LVM is more useful than I thought.  If you use LVM with XFS or JFS then you
may have to create partitions/filesystems and copy data to "resize" which does
reduce its advantage.

Anyway the example you gave isn't as inflexible as you suppose.  You could
remount hda6 readonly (online), copy to unused diskspace, remount and bind
readonly in new location, unmount and delete hda6, extend hda5 and grow the fs.
Only one or two partitions are unmounted.

Naturally it's not as flexible (although you don't have to fiddle with volume
groups and logical volumes). This sort of situation is what LVM was designed
for.

>>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,
> 
> 
> LVM isn't some sort of "RAID". That's what RAID is for. Actually, it's not
> unusual to use (Software-)RAID and LVM in combination.

LVM supports striping, so it tries to be a pseudo-RAID.  The HOWTO only talks 
about physical extents but I am sure it can run over a proper RAID layer.

>>>Wrong. On what experience do you base your conclusion? On your false reading?
>>
>>Based on the HOWTO.  Please read it.
> 
> 
> So, you base this on *no* experience?

It is reasonable to assume the HOWTO is written by people knowledgeable and
favourable to LVM.  If you think it has been sabotaged by a secret cabal of
anti-LVM zealots then perhaps you should offer to rewrite it.
But please read it first.

> OTT?

<http://www.google.com/search?hl=en&q=usenet+acronyms+OTT>

It's a common acronym, and most posters can do a simple google search.

Toby