Booting - Enterprise Volume Management System

Alexander Skwar listen at alexander.skwar.name
Fri Aug 11 17:06:11 UTC 2006


· Toby Kelsey <toby_kelsey at ntlworld.com>:

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

Well, depends. But anyway, I give you so much, that I agree,
that this is one of the reasons why I don't use ext3.

> Repetition has 
> not improved your argument.

Well, if you repeat yourself, then I've got to repeat myself as well.

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

Who says that, this is the *main* advantage (on Linux)?

Anyway, as disk usage normally grows (at least in my experience),
that's not much of a weak point.

> using JFS and XFS 
> negate that - except for growth into unused disk-space.

Which is, what normally happens.

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

How? 

> It 
> seems to me that LVM is mainly advantageous when you have limited disk-space,

And also, if you've got a lot of space. But who does NOT have
limited diskspace?

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

Reason: People started of wrong by having everything on one *FILESYSTEM*.

> Mainly so people can simplify backup processes,

Another advantage of LVM - snapshots.

> separate  
> user data from system data, allow safe reinstalls, and increase capacity by
> upgrading drives.

Yep.

> I don't recall anyone asking to do it just so they can use a 
> different filesystem for /home.

Do you actually understand yourself, what you write? If /home is moved
off the / filesystem, it is on a different filesystem.

> Your requirements clearly differ. 

What are you talking about?

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

I never had this problem.

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

Thanks.

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

ext3 is neither the common case, nor do you *HAVE* to unmount - You're
not forced to unmount. Now, it *might* be a good idea, but contrary
to what you say, ext3 doesn't *HAVE* to be unmounted.

> If as you say online resizing is completely safe 

It is very much safe. I would never say, that anything 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.

What are you talking about?

Resizing a xfs filesystem is done by doing "xfs_growfs /foo" and
JFS: "mount -o resize,remount /bar". No copying required.

> Anyway the example you gave isn't as inflexible as you suppose.  You could
> remount hda6 readonly (online),

What do you do, if hda6 has to be rw?

> copy to unused diskspace, remount and bind 
> readonly in new location, unmount and delete hda6,

I can't unmount and delete hda6. What do you do, if you've got 100GB 
unallocated, need to make hda5 50gb bigger and hda6 is 2gb in size?

> extend hda5 and grow the fs. 
> Only one or two partitions are unmounted.

Which is a no-go. Especially, if there are solutions, which don't
require this.

> Naturally it's not as flexible (although you don't have to fiddle with volume
> groups and logical volumes).

Uhm - you don't fiddle with VGs, normally. And "fiddling" with LV: 
lvextend -L+50g /dev/sys/hda5. Not quite as hard, as you try to put
it.

> This sort of situation is what LVM was designed 
> for.

Yes.

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

True.

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

PEs and "proper RAID" doesn't have anything to do with each other.

A Volume Group consists of many Physical Extents (PEs). PEs are "blocks"
which get assigned to Logical Volumes (LVs). RAID is at least two layers
"below" VG - a VG is made of Physical Volumes (PVs); PVs are "partitions",
so to speak - and as a partition, a partition which resides on a RAID
can be used.

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

Yes.

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

Anyway, what you write is based on NO experience?

>> OTT?
> 
> <http://www.google.com/search?hl=en&q=usenet+acronyms+OTT>
> 
> It's a common acronym,

Actually, it is not.

> and most posters can do a simple google search. 

:)

Alexander Skwar
-- 
Richter: "Ich spreche Sie hiermit frei von der Anklage, sie hätten die
10.000 DM gestohlen."
Angeklagter: "Prima. Darf ich das Geld dann behalten?"






More information about the ubuntu-users mailing list