Booting - Enterprise Volume Management System

[Alexander Skwar]

· Toby Kelsey <toby_kelsey at ntlworld.com>:
> Alan Mckinnon wrote:
>> On Fri, 2006-08-11 at 12:26 +0100, Toby Kelsey wrote:

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

No, as the usual "direction" (ie. making larger) is supported.

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

Yup. I was surprised as well.

http://linuxgazette.net/122/TWDT.html#piszcz
http://osnews.com/read_thread.php?news_id=15129&comment_id=141566
http://www.debian-administration.org/articles/388
http://linuxgazette.net/102/piszcz.html
http://www.quest-pipelines.com/newsletter-v2/linux2.htm

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

As making larger is supported, you gain something by using
LVM. You do so, as, normally, it's not possible to make
old fashioned partitions larger - at least not online and
at least not easily.

> I agree, there are many problems with one big partition.  One big logical volume
> also has a corruption risk.

Well, one LV which spans the whole VG which spans all of the
existing PVs is bad. Yes, I agree.

That's not how LVM is usually used, I'd suppose (I don't know,
for sure though - how could I?).

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

Hm, everything is possible, but that would be an extreme bug.

Do you know of *ONE* case where something like this has happened?

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

Where do I claim this? I don't claim that the Howto is outdated.
At best, I claim that certain sections are outdated. The howto
itself is still current, as the technology (ie. LVM or LVM2)
hasn't changd.

> Unknown bugs may always exist, does that mean we should ignore reports of known
> bugs?

If they are outdated - yes.

> Are HOWTO authors likely to report problems if there are none?

They are likely, to not REMOVE reports. It's sort of like
those "documentation" you get when you buy medicine. It's
ultra long with ultra rare cases, but it's of course good
to mention even those ultra rare cases.

> This bug  
> mention is disappointingly vague about kernel versions, but that doesn't
> discount it.

As far as that's concerned, the age of the Howto discounts it. 
Last update was about a year ago. That's ancient.

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

Why is JFS a 30mph zone? It's rather a 149mph zone, normally.

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

Well, but as filesystems usually just grow, that's not so much
of a disadvantage as you put it. Besides, LVM has MORE advantages
than just this one.

>> Software raid will always be slower than LVM,

I'm surprised - do you have any benchmarks which proove that?

Alexander Skwar
-- 
Der Richter : "Die nächste Person, die die Verhandlung
unterbricht, wird nach Hause geschickt!"
Der Gefangene: Hurra!"