bk://device-mapper.bkbits.net/2.5-remove-lvm
This large patch completely removes LVM from the 2.5 tree. Please
apply. Yes it really has spread as far as linux/list.h and
linux/kdev_t.h !
- Joe Thornber
On Tue, 1 Oct 2002, Joe Thornber wrote:
> bk://device-mapper.bkbits.net/2.5-remove-lvm
>
> This large patch completely removes LVM from the 2.5 tree. Please
> apply. Yes it really has spread as far as linux/list.h and
> linux/kdev_t.h !
Seconded - LVM in the tree is thoroughly dead.
Speaking of which, would Intermezzo maintainers care to port the thing
to 2.5? If it's abandoned - at least say so ;-/
On Tue, Oct 01 2002, Joe Thornber wrote:
> bk://device-mapper.bkbits.net/2.5-remove-lvm
>
> This large patch completely removes LVM from the 2.5 tree. Please
> apply. Yes it really has spread as far as linux/list.h and
> linux/kdev_t.h !
Good to see you follow up on that. The (by far) more important thing is
dm for 2.5 -- where is it?
--
Jens Axboe
On Tue, Oct 01, 2002 at 04:40:36PM +0200, Jens Axboe wrote:
> The (by far) more important thing is dm for 2.5 -- where is it?
Not far away ... I'll post more info along with the bk URL later today.
Joe Thornber
A Logical Volume Manager is needed on Unix servers, and so it is needed
also on Linux.
If this LVM is obsoleted, then when will LVM2 be merged?
really we cannot have a 2.6 or 3.0 tree without a Volume Manager, it would
be a big fault.
Luigi
On Tue, 1 Oct 2002, Alexander Viro wrote:
> Date: Tue, 1 Oct 2002 10:15:26 -0400 (EDT)
> From: Alexander Viro <[email protected]>
> To: Joe Thornber <[email protected]>
> Cc: [email protected], Dave Jones <[email protected]>,
> Linus Torvalds <[email protected]>
> Subject: Re: [PATCH] Remove LVM from 2.5 (resend)
>
>
>
> On Tue, 1 Oct 2002, Joe Thornber wrote:
>
> > bk://device-mapper.bkbits.net/2.5-remove-lvm
> >
> > This large patch completely removes LVM from the 2.5 tree. Please
> > apply. Yes it really has spread as far as linux/list.h and
> > linux/kdev_t.h !
>
> Seconded - LVM in the tree is thoroughly dead.
>
> Speaking of which, would Intermezzo maintainers care to port the thing
> to 2.5? If it's abandoned - at least say so ;-/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, Oct 01, 2002 at 04:52:44PM +0200, [email protected] wrote:
> A Logical Volume Manager is needed on Unix servers, and so it is needed
> also on Linux.
> If this LVM is obsoleted, then when will LVM2 be merged?
> really we cannot have a 2.6 or 3.0 tree without a Volume Manager, it would
> be a big fault.
No-one suggested 2.6.0 shipping without /something/, but having a dead
LVM1 in _2.5_ doesn't help anyone. We've gone 6 months with it being in
a broken/uncompilable state, going another month without it isn't a big
deal. Getting something in before halloween is however a goal the
Sistina folks should be aiming for.
Consider it patch 1/2 of the device mapper merge 8-)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Tue, Oct 01 2002, Dave Jones wrote:
> Consider it patch 1/2 of the device mapper merge 8-)
Indeed, the patches are also arriving out of order though, LVM remove
patch should be 2/2 not 1/2. IMO.
--
Jens Axboe
On Tue, Oct 01, 2002 at 06:06:08PM +0200, Jens Axboe wrote:
> On Tue, Oct 01 2002, Dave Jones wrote:
> > Consider it patch 1/2 of the device mapper merge 8-)
>
> Indeed, the patches are also arriving out of order though, LVM remove
> patch should be 2/2 not 1/2. IMO.
If LVM remotely worked I would agree with you.
Joe Thornber
On Tue, Oct 01 2002, Joe Thornber wrote:
> On Tue, Oct 01, 2002 at 06:06:08PM +0200, Jens Axboe wrote:
> > On Tue, Oct 01 2002, Dave Jones wrote:
> > > Consider it patch 1/2 of the device mapper merge 8-)
> >
> > Indeed, the patches are also arriving out of order though, LVM remove
> > patch should be 2/2 not 1/2. IMO.
>
> If LVM remotely worked I would agree with you.
No matter the state of lvm, it's much better to day "1, here's the
replacement - 2, rip the old one out". What if device mapper for 2.5
really sucks? Maybe it's so bad that we'd rather fix up lvm1? Apparently
davej has patches that sort-of makes lvm work.
It's not likely, but still :-)
--
Jens Axboe
On Oct 01, 2002 10:15 -0400, Alexander Viro wrote:
> Speaking of which, would Intermezzo maintainers care to port the thing
> to 2.5? If it's abandoned - at least say so ;-/
One of the Clusterfs developers is now working on updating InterMezzo
again...
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
On Tue, 01 Oct 2002, Dave Jones wrote:
> On Tue, Oct 01, 2002 at 04:52:44PM +0200, [email protected] wrote:
> > A Logical Volume Manager is needed on Unix servers, and so it is needed
> > also on Linux.
> > If this LVM is obsoleted, then when will LVM2 be merged?
> > really we cannot have a 2.6 or 3.0 tree without a Volume Manager, it would
> > be a big fault.
>
> No-one suggested 2.6.0 shipping without /something/, but having a dead
> LVM1 in _2.5_ doesn't help anyone. We've gone 6 months with it being in
> a broken/uncompilable state, going another month without it isn't a big
> deal. Getting something in before halloween is however a goal the
> Sistina folks should be aiming for.
How about EVMS kernel-space merge instead?
On 2002-10-01T16:48:08,
Dave Jones <[email protected]> said:
> No-one suggested 2.6.0 shipping without /something/, but having a dead
> LVM1 in _2.5_ doesn't help anyone.
Has the cabal (which does not exist) reached a verdict on the preferred
solution for 2.6 yet, so that we can sort of see where things are going?
Who has the hat "Volume Manager" on his gullible head? ;-)
I'll again pipe in for the radical solution: EVMS(powerful) on top of
device-mapper(elegant).
EVMS also shows promise as they are working on _open_ cluster support, which I
think will be one of the big things to happen in 2.7.
Rip out the compatibility cruft (LVM1, md and maybe others), as EVMS can do
everything they can as promised.
I'd understand if the compatibility "cruft" was still left in for 2.6 so
people could use the 2.6 timeframe to migrate and then finally kick it out
first thing in 2.7.
But then, I have a strong, explosive allergy to duplicated chunks of code.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Principal Squirrel
Research and Development, SuSE Linux AG
``Immortality is an adequate definition of high availability for me.''
--- Gregory F. Pfister
That was exactky what I was meaning with my first post.
LVM should stay included untill LVM2 is ready
to be merged. That would be metodologically and logically correct.
What is LVM2 is not ready for 2.6? then you could still fix old LVM.
Luigi
On Tue, 1 Oct 2002, Jens Axboe wrote:
> Date: Tue, 1 Oct 2002 18:41:36 +0200
> From: Jens Axboe <[email protected]>
> To: Joe Thornber <[email protected]>
> Cc: Dave Jones <[email protected]>, [email protected],
> Alexander Viro <[email protected]>, [email protected],
> Linus Torvalds <[email protected]>
> Subject: Re: [PATCH] Remove LVM from 2.5 (resend)
>
> On Tue, Oct 01 2002, Joe Thornber wrote:
> > On Tue, Oct 01, 2002 at 06:06:08PM +0200, Jens Axboe wrote:
> > > On Tue, Oct 01 2002, Dave Jones wrote:
> > > > Consider it patch 1/2 of the device mapper merge 8-)
> > >
> > > Indeed, the patches are also arriving out of order though, LVM remove
> > > patch should be 2/2 not 1/2. IMO.
> >
> > If LVM remotely worked I would agree with you.
>
> No matter the state of lvm, it's much better to day "1, here's the
> replacement - 2, rip the old one out". What if device mapper for 2.5
> really sucks? Maybe it's so bad that we'd rather fix up lvm1? Apparently
> davej has patches that sort-of makes lvm work.
>
> It's not likely, but still :-)
>
> --
> Jens Axboe
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
EVMS is powerfull, but actually has a so ugly command line...
fortunatelly EVMS architecture command line could be exchanged...
On Tue, 1 Oct 2002, Matthias Andree wrote:
> Date: Tue, 1 Oct 2002 21:12:49 +0200
> From: Matthias Andree <[email protected]>
> To: [email protected]
> Cc: Dave Jones <[email protected]>, [email protected],
> Alexander Viro <[email protected]>,
> Joe Thornber <[email protected]>,
> Linus Torvalds <[email protected]>
> Subject: Re: [PATCH] Remove LVM from 2.5 (resend)
>
> On Tue, 01 Oct 2002, Dave Jones wrote:
>
> > On Tue, Oct 01, 2002 at 04:52:44PM +0200, [email protected] wrote:
> > > A Logical Volume Manager is needed on Unix servers, and so it is needed
> > > also on Linux.
> > > If this LVM is obsoleted, then when will LVM2 be merged?
> > > really we cannot have a 2.6 or 3.0 tree without a Volume Manager, it would
> > > be a big fault.
> >
> > No-one suggested 2.6.0 shipping without /something/, but having a dead
> > LVM1 in _2.5_ doesn't help anyone. We've gone 6 months with it being in
> > a broken/uncompilable state, going another month without it isn't a big
> > deal. Getting something in before halloween is however a goal the
> > Sistina folks should be aiming for.
>
> How about EVMS kernel-space merge instead?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 2002-10-01 at 19:42, Lars Marowsky-Bree wrote:
> I'll again pipe in for the radical solution: EVMS(powerful) on top of
> device-mapper(elegant).
The more shit you pile the more likely your compost heap is to collapse.
And with some of the stuff in EVMS I don't want to be around when it
does
> EVMS also shows promise as they are working on _open_ cluster support, which I
> think will be one of the big things to happen in 2.7.
DM is small and clean. It may well be that if we go the DM way (and I
think we should) that those bits of EVMS that we want (like cluster)
actually come out a lot cleaner than in EVMS itself
Alan
On Wed, Oct 02, 2002 at 02:00:58AM +0100, Alan Cox wrote:
> DM is small and clean. It may well be that if we go the DM way (and I
> think we should) that those bits of EVMS that we want (like cluster)
> actually come out a lot cleaner than in EVMS itself
DM is small and clean because it's severely lacking in functionality.
Last I checked it couldn't do RAID 5 or r/w snapshots without
completely bypassing its core infrastructure (since you're no longer
just doing simple block remapping at that point), and once you add all
that stuff, it's likely to become much more complex.
- Ted
On Wed, 2002-10-02 at 05:24, Theodore Ts'o wrote:
> DM is small and clean because it's severely lacking in functionality.
> Last I checked it couldn't do RAID 5 or r/w snapshots without
> completely bypassing its core infrastructure (since you're no longer
> just doing simple block remapping at that point), and once you add all
> that stuff, it's likely to become much more complex.
Last time I checked we already had a perfectly good md driver for the
raid5 handling
On 2002-10-02T14:34:29,
Alan Cox <[email protected]> said:
> > completely bypassing its core infrastructure (since you're no longer
> > just doing simple block remapping at that point), and once you add all
> > that stuff, it's likely to become much more complex.
> Last time I checked we already had a perfectly good md driver for the
> raid5 handling
Not entirely. I gather that EVMS AIX RAID code has some very nice properties
like journaling (which of course cannot be mapped directly onto md), greatly
speeding up rebuilds after a crash.
The MD code will also show some very nice failure scenarios in a clustered
software-RAID scenario, which the EVMS code could (from what I know) address.
(Whether that's a sensible scenario or not is left as an exercise to the
reader...)
I'll also admit that the "EVMS on top of DM and rip out everything else" was
slightly over the top on purpose, though I'd be somewhat annoyed if we had
EVMS (with its compatibility modules) and the modules it is supposed to be
compatible with (ie, md) at the same time, with duplicated code. That would
suck. Unless of course it was indeed meant as a transition period.
I'd be fine if someone said "We'll have EVMS, md and DM in 2.6 and then sort
the mess in 2.7.", I'm just curious what the goal is. Right now, there's no
working code in 2.5 nor a vision, which is obviously a major bug.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Principal Squirrel
Research and Development, SuSE Linux AG
``Immortality is an adequate definition of high availability for me.''
--- Gregory F. Pfister
On Wed, 2002-10-02 at 15:54, Lars Marowsky-Bree wrote:
> I'd be fine if someone said "We'll have EVMS, md and DM in 2.6 and then sort
> the mess in 2.7.", I'm just curious what the goal is. Right now, there's no
> working code in 2.5 nor a vision, which is obviously a major bug.
Look at history - if such a mess got in, it would never get sorted.
On 2002-10-02T18:09:31,
Alan Cox <[email protected]> said:
> > I'd be fine if someone said "We'll have EVMS, md and DM in 2.6 and then sort
> > the mess in 2.7.", I'm just curious what the goal is. Right now, there's no
> > working code in 2.5 nor a vision, which is obviously a major bug.
> Look at history - if such a mess got in, it would never get sorted.
Sounds like a good reason to do the cleanup immediately, then.
Deleting code, I can do that ;-)
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Principal Squirrel
Research and Development, SuSE Linux AG
``Immortality is an adequate definition of high availability for me.''
--- Gregory F. Pfister
On Wed, 2002-10-02 at 23:29, Lars Marowsky-Bree wrote:
> Sounds like a good reason to do the cleanup immediately, then.
> Deleting code, I can do that ;-)
Absolutely - taking the core EVMS(say the core code and the bits to do
LVM1) and polishing them up to be good clean citizens without code
duplication and other weirdness would be a superb start for EVMS as a
merge candidate. The rest can follow a piece at a time once the core is
right if EVMS is the right path
On Oct 02, 2002 23:46 +0100, Alan Cox wrote:
> Absolutely - taking the core EVMS(say the core code and the bits to do
> LVM1) and polishing them up to be good clean citizens without code
> duplication and other weirdness would be a superb start for EVMS as a
> merge candidate. The rest can follow a piece at a time once the core is
> right if EVMS is the right path
I actually see EVMS as the "VFS for disk devices". It is a very good
way to at allow dynamic disk device allocation, and could relatively
easily be modified to use all of the "legacy" disk major devices and
export only real partitions (one per minor).
You could have thousands of disks and partitions without the current
limitations on major/minor device mapping.
This was one of the things that Linus was pushing for when 2.5 started.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
On Wed, 2 Oct 2002, Andreas Dilger wrote:
> On Oct 02, 2002 23:46 +0100, Alan Cox wrote:
> > Absolutely - taking the core EVMS(say the core code and the bits to do
> > LVM1) and polishing them up to be good clean citizens without code
> > duplication and other weirdness would be a superb start for EVMS as a
> > merge candidate. The rest can follow a piece at a time once the core is
> > right if EVMS is the right path
>
> I actually see EVMS as the "VFS for disk devices". It is a very good
> way to at allow dynamic disk device allocation, and could relatively
> easily be modified to use all of the "legacy" disk major devices and
> export only real partitions (one per minor).
>
> You could have thousands of disks and partitions without the current
> limitations on major/minor device mapping.
>
> This was one of the things that Linus was pushing for when 2.5 started.
... and you don't need EVMS for that.
On 10/03/02 07:22, Alexander Viro wrote:
>
> On Wed, 2 Oct 2002, Andreas Dilger wrote:
>
>
>>On Oct 02, 2002 23:46 +0100, Alan Cox wrote:
>>
>>>Absolutely - taking the core EVMS(say the core code and the bits to do
>>>LVM1) and polishing them up to be good clean citizens without code
>>>duplication and other weirdness would be a superb start for EVMS as a
>>>merge candidate. The rest can follow a piece at a time once the core is
>>>right if EVMS is the right path
>>
>>I actually see EVMS as the "VFS for disk devices". It is a very good
>>way to at allow dynamic disk device allocation, and could relatively
>>easily be modified to use all of the "legacy" disk major devices and
>>export only real partitions (one per minor).
>>
>>You could have thousands of disks and partitions without the current
>>limitations on major/minor device mapping.
>>
>>This was one of the things that Linus was pushing for when 2.5 started.
>
>
> ... and you don't need EVMS for that.
But EVMS would be an excellent substitute in the mean time.
Better to having something excellent now than something perfect but
too late.
The EVMS guys have done a great job of cleanly integrating with 2.5,
the single additional interface they needed to add to genhd.c is
testament to their consideration of these issues.
IBM seem to have done a great job creating the most extensive and
complete logical volume manager for Linux (including a suite of end
user tools much more extensive than LVM). They have also shown the
commitment to keep it current and cleary are way further ahead than
any other contender. It would be horrible if not getting the nod from
the right friends deprived users of a *complete* logical volume manager
in 2.5 anytime soon.
Peace, love and Linux ;)
~mc
On Thu, 2002-10-03 at 06:50, Michael Clark wrote:
> > ... and you don't need EVMS for that.
>
> But EVMS would be an excellent substitute in the mean time.
>
> Better to having something excellent now than something perfect but
> too late.
You can see who around here has maintained kernel code and who hasnt.
You don't want a substitute in the mean time, because then you have to
get rid of it
On 10/03/02 20:38, Alan Cox wrote:
> On Thu, 2002-10-03 at 06:50, Michael Clark wrote:
>
>>>... and you don't need EVMS for that.
>>
>>But EVMS would be an excellent substitute in the mean time.
>>
>>Better to having something excellent now than something perfect but
>>too late.
>
>
> You can see who around here has maintained kernel code and who hasnt.
> You don't want a substitute in the mean time, because then you have to
> get rid of it
Like LVM ;)
/me submits to the masters and waits in subjugation.
Just hoping for good Volume Manager in 2.6 and EVMS looks good
to me from an end user perspective, and also seems quite timely.
~mc
On 10/03/02 23:07, Shawn wrote:
> On 10/03, Michael Clark said something like:
>
>>On 10/03/02 20:38, Alan Cox wrote:
>>
>>>On Thu, 2002-10-03 at 06:50, Michael Clark wrote:
>>>
>>>
>>>>>... and you don't need EVMS for that.
>>>>
>>>>But EVMS would be an excellent substitute in the mean time.
>>>>
>>>>Better to having something excellent now than something perfect but
>>>>too late.
>>>
>
> This statement is misleading; in no way is EVMS intended as an
> interim solution to a problem addressed easier in other ways. It's
> a fundamental change which happens to address certain critical issues
> and also adds functionality whiz-bangs.
Yes, i agree. It's not the original intention of EVMS to be used
as a unified interface to all linux block devices. Although it
could be used in that way if desired by any individual user -
to provide a solution to the consistent block device naming issue.
>>>You can see who around here has maintained kernel code and who hasnt.
>>>You don't want a substitute in the mean time, because then you have to
>>>get rid of it
>>
>>Like LVM ;)
>
>
> Not quite...
Well, existing LVM does appear to be a subsitute for a better solution
(dm or EVMS) for which it's time has come to be removed.
~mc
On 10/03, Michael Clark said something like:
> On 10/03/02 20:38, Alan Cox wrote:
> > On Thu, 2002-10-03 at 06:50, Michael Clark wrote:
> >
> >>>... and you don't need EVMS for that.
> >>
> >>But EVMS would be an excellent substitute in the mean time.
> >>
> >>Better to having something excellent now than something perfect but
> >>too late.
This statement is misleading; in no way is EVMS intended as an
interim solution to a problem addressed easier in other ways. It's
a fundamental change which happens to address certain critical issues
and also adds functionality whiz-bangs.
> > You can see who around here has maintained kernel code and who hasnt.
> > You don't want a substitute in the mean time, because then you have to
> > get rid of it
>
> Like LVM ;)
Not quite...
> /me submits to the masters and waits in subjugation.
>
> Just hoping for good Volume Manager in 2.6 and EVMS looks good
> to me from an end user perspective, and also seems quite timely.
Me too.
--
Shawn Leas
[email protected]
I had a friend who was a clown... when he died, all his friends went to the
funeral in one car...
-- Stephen Wright
On Thu, 2002-10-03 at 10:22, Michael Clark wrote:
> On 10/03/02 23:07, Shawn wrote:
> > On 10/03, Michael Clark said something like:
> >
> >>On 10/03/02 20:38, Alan Cox wrote:
> >>
> >>>On Thu, 2002-10-03 at 06:50, Michael Clark wrote:
> >>>
> >>>
> >>>>>... and you don't need EVMS for that.
> >>>>
> >>>>But EVMS would be an excellent substitute in the mean time.
> >>>>
> >>>>Better to having something excellent now than something perfect but
> >>>>too late.
> >>>
> >
> > This statement is misleading; in no way is EVMS intended as an
> > interim solution to a problem addressed easier in other ways. It's
> > a fundamental change which happens to address certain critical issues
> > and also adds functionality whiz-bangs.
>
> Yes, i agree. It's not the original intention of EVMS to be used
> as a unified interface to all linux block devices. Although it
> could be used in that way if desired by any individual user -
> to provide a solution to the consistent block device naming issue.
This is true, but the major problem comes of upgrading and compatibility
issues with old versions of LVM, etc. The usual stuff, IMHO.
> >>>You can see who around here has maintained kernel code and who hasnt.
> >>>You don't want a substitute in the mean time, because then you have to
> >>>get rid of it
> >>
> >>Like LVM ;)
> >
> >
> > Not quite...
>
> Well, existing LVM does appear to be a subsitute for a better solution
> (dm or EVMS) for which it's time has come to be removed.
I'm not sure what you're saying here. EVMS is good, but I believe that
LVM and EVMS serve two different purposes, mainly with regard to the
type of environments each is used in.
I've attempted to contact Heinz twice, I hope he responds about this
soon. I like LVM for it's simplicity, and ease of use. Simple tools, and
methods that get the job done.
> ~mc
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/