Linux LVM users
 help / color / mirror / Atom feed
From: Clint Byrum <cbyrum@spamaps.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM2 features
Date: Fri, 15 Oct 2004 10:42:58 -0700	[thread overview]
Message-ID: <1097862178.21375.20.camel@localhost> (raw)
In-Reply-To: <20041015150823.GB6352@omnifarious.org>

On Fri, 2004-10-15 at 08:08 -0700, Eric Hopper wrote:
> On Fri, Oct 15, 2004 at 10:15:07AM +0200, John Seifarth wrote:
> > Eric Hopper posted the query below last weekend, but I've seen no 
> > replies on the list.
> 
> Here are the things I've seen...
> 

<snip>

> pvmove has lots of weird and arcane limitations that make no sense to me
> at all.  It acted very strangely and seemed to lock parts of my system
> when I tried it with a fresh Fedora Core 2 install, and I've been afraid
> to try it since.  I see lots of messages flying back and forth about
> people having to hand-construct command lines to move specific extents
> because of some odd limitation of pvmove.
> 
> I also see little hard information about these limitations or why they
> exist.  I see all kinds of confused posts stating that this detail or
> that detail is the reason some particular operation doesn't work quite
> right.
> 


As a user on the outside who loved LVM1, and has grown to love LVM2, I
have to say I disagree with your points. This one, for instance, isn't
true. The hard data is that the allocation routines in pvmove don't yet
understand how to split the destination among two non-contiguous blocks
of physical extents. So, even if vgdisplay shows 100GB free, and you
only want to move 30GB .. you *might* have to move it in pieces, if the
free space isn't in a contiguous block.

Is that as nice as pvmove in lvm1? No. Are the other positives in LVM2
worth dealing with this minor inconvenience? IMHO, Yes!

> I used to know some of the LVM developers personally, and this list used
> to be much more open about the internal workings of LVM and there used
> to be people who would state plainly and authoritatively what was
> causing some particular problem.  I remember fondly the debates over
> getting /boot onto an LVM partition.
> 

I haven't seen any dodging. What I've seen is a tad less active
participation in the mailing list by the developers. This makes sense to
me.. they're busy making LVM2 better.

> I don't know what's happened or why.
> 
> From the outside, it seems as if LVM2 (which by all accounts is much
> higher quality code) was rushed into production before it was
> feature-comparable to LVM1, and all the developers are embarassed about
> it and not talking frankly about what's wrong.  If this were not Open
> Source, I'd say the company they worked for was discouraging them from
> discussing the limitations openly and leaving the users to guess and
> talk amongst themselves about them.
> 

This attitude confuses me. Open Source code doesn't really get "rushed
to production". If it sucks, people don't use it. There are no big
emotional attachments to it like with commercial software, where huge
amounts of licensing costs get spent on bad software. I haven't seen
anything "wrong." Bugs happen, and they're being fixed fairly quickly. 

Maybe its just that this list has reduced in importance wrt LVM2?

-- 
Clint Byrum <cbyrum@spamaps.org>

  reply	other threads:[~2004-10-15 17:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-10  3:26 [linux-lvm] LVM2 features Eric Hopper
2004-10-15  8:15 ` John Seifarth
2004-10-15 15:08   ` Eric Hopper
2004-10-15 17:42     ` Clint Byrum [this message]
2004-10-15 21:28       ` Eric Hopper
2004-10-15 12:55 ` Alasdair G Kergon
  -- strict thread matches above, loose matches on Subject: below --
2004-10-15 11:01 Kai Leibrandt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1097862178.21375.20.camel@localhost \
    --to=cbyrum@spamaps.org \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox