From: Eric Hopper <hopper@omnifarious.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM2 features
Date: Fri, 15 Oct 2004 14:28:34 -0700 [thread overview]
Message-ID: <20041015212834.GD6352@omnifarious.org> (raw)
In-Reply-To: <1097862178.21375.20.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]
On Fri, Oct 15, 2004 at 10:42:58AM -0700, Clint Byrum wrote:
> 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.
That implies another weird problem, which is that you can't pvmove
something in a single chunk unless you have the much free space, which
is also somewhat non-intuitive.
> Is that as nice as pvmove in lvm1? No. Are the other positives in LVM2
> worth dealing with this minor inconvenience? IMHO, Yes!
What are those positives? I don't deny that they exist. I know, for
example, the the whole idea of having device mapper for doing the raw
block mapping, and actually doing most of the work of keeping track of
LVM objects and structures in userland is an excellent idea, and is a
much cleaner split than the LVM1 userland/kernel split.
> 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.
Maybe the user community is changing, so the quality of the questions
and the percentage of high quality answers is going down. Since it
isn't so much of a cutting edge thing anymore, the scaling from
developer to user is no longer quite so smooth. That observation is not
meant as a negative reflection of the user community. This happens to
every piece of software as it enters widespread use. Not everybody can
be experts in everything.
> This attitude confuses me. Open Source code doesn't really get "rushed
> to production".
Actually, it does. The Linux kernel development model has tended to
cause things to get pushed into 'production' (i.e. major .even kernel
releases). Perhaps if kernel release cycles were shorter, this effect
wouldn't be so pronounced.
> 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.
Well, the developers themselves usually have a pretty strong attachment
to the idea of widespread usage of their software. I know that's my
biggest reward as a developer.
> Maybe its just that this list has reduced in importance wrt LVM2?
I'm guessing that's the case because of the user community changes I
mentioned earlier.
Have fun (if at all possible),
--
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg." --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company." -- Mark Twain
-- Eric Hopper (hopper@omnifarious.org http://www.omnifarious.org/~hopper) --
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-10-15 21:28 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
2004-10-15 21:28 ` Eric Hopper [this message]
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=20041015212834.GD6352@omnifarious.org \
--to=hopper@omnifarious.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