Re: [linux-lvm] LVM 1.0 release decision

Re: [linux-lvm] LVM 1.0 release decision

[Adrian Phillips]

>>>>> "Heinz" == Heinz J Mauelshagen <Mauelshagen@sistina.com> writes:

    Heinz> As most of you probably know, we've got criticism a couple
    Heinz> of weeks ago about our Linux kernel patch policy causing
    Heinz> the LVM vanilla kernel code to differ from the one we
    Heinz> release directly.

    Heinz> In order to avoid this difference we provide smaller
    Heinz> patches more often now.  We have started already with a
    Heinz> subset of about 50 necessary patches.

    Heinz> Even though we get kind support from Alan Cox to get those
    Heinz> QAed and integrated, the pure amount of patches will take
    Heinz> at least a couple of weeks to make it in.

Uh, presumably you're talking 2.4 here. Seeing as each new 2.2 release
has a good number of weeks in between it would be not worth delaying
a LVM release because of that, and the same would seem to go for 2.4
as well as it becomes more stable.

    Heinz> This leads to the dilemma, that trying to avoid further
    Heinz> differences between our LVM releases and the stock kernel
    Heinz> code would force us into postponing the pending LVM 1.0
    Heinz> release accordingly which OTOH is incovenient for the LVM
    Heinz> user base.

Just release 1.0 with patches to a certain base 2.4.4 and 2.2.19 and
when 2.4.5 comes out with all the LVM patches init you just mention
that 2.4.5 has all the relevant patches.

    Heinz> In regard to this situation we'ld like to know about your
    Heinz> oppinion on the following request: is it acceptable to
    Heinz> release 1.0 soon *before* all patches to reach the 1.0 code
    Heinz> status are in vanilla (presumed that we provide them with
    Heinz> our release as we always did before)?

This is assuming I've actually completely understood what you're
talking about :-)

Sincerely,

Adrian Phillips

-- 
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now?  [OK]

Re: [linux-lvm] LVM 1.0 release decision

[Torsten Landschoff]

On Fri, May 11, 2001 at 03:53:11PM +0000, Heinz J. Mauelshagen wrote:
> In regard to this situation we'ld like to know about your oppinion on the
> following request:
> is it acceptable to release 1.0 soon *before* all patches to reach the 1.0
> code status are in vanilla (presumed that we provide them with our release as
> we always did before)?

My stance would be to do a pre-release of the to-be-1.0 code. Reasons:

- as you said, it would be good for the user base
- OTOH I would expect the lvm code in the kernel to become a bit 
  different from what you have now as a matter of the code review.

> Thanks for your support!

Thanks for LVM :-)

Greetings

	Torsten

Re: [linux-lvm] LVM 1.0 release decision

[Terje Kvernes]

"Heinz J. Mauelshagen" <Mauelshagen@sistina.com> writes:

> This leads to the dilemma, that trying to avoid further differences
> between our LVM releases and the stock kernel code would force us
> into postponing the pending LVM 1.0 release accordingly which OTOH
> is incovenient for the LVM user base.

  why is postponing LVM 1.0 inconvenient for the LVM user base? the
  people using it now won't feel the difference, and people not using
  it will be delayed some time. as much as I love LVM, I don't see the
  problem. release 1.0 when things fall into place.

> In regard to this situation we'ld like to know about your oppinion
> on the following request: is it acceptable to release 1.0 soon
> *before* all patches to reach the 1.0 code status are in vanilla
> (presumed that we provide them with our release as we always did
> before)?

  I'm not sure there's a point to it. what will happen is just that
  people will yet again have to come get apparently external patches
  for something already in the kernel. I think marking the end of that
  with 1.0 would be nice.

  this reminds me of XFS to be honest -- and that annoys me a great
  deal. I want to test XFS, but currently I can't. because after LVM
  and ReiserFS are patched (they pull rank :), the XFS-patches botch
  badly. and they're far from in sync with current kernels.

  IMHO: getting all the patches into the kernel, makes it a _lot_
  easier for the LVM user base. because they can _then_ apply other
  patches for other projects of they want to. it's also easier on
  other developers of the same reason.

> We'll gather your answers for some days and will send the conclusion
> to the lists.

  okies :)

-- 
Terje - a very happy LVM user.

Re: [linux-lvm] LVM 1.0 release decision

[Christoph Hellwig]

On Fri, May 11, 2001 at 03:53:11PM +0000, Heinz J. Mauelshagen wrote:
> In regard to this situation we'ld like to know about your oppinion on
> the following request:
> is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
> status are in vanilla (presumed that we provide them with our release as we
> always did before)?

IMHO you should get out a 0.9.1final and sync the stock kernel before...
If and only IF 1.0 will change the IOP again I don't want to see it all
in stock 2.4.0 - the stable series should stay backward compatible.
Otherwise:  just relese 1.0 and send the diffs to Alan and Linus - if
they think you changes are ok they will merge it.

Vendors interested in having 1.0 in their kernels will put it in anyway.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

[linux-lvm] LVM 1.0 release decision

[Heinz J. Mauelshagen]

As most of you probably know, we've got criticism a couple of weeks ago about
our Linux kernel patch policy causing the LVM vanilla kernel code to differ
from the one we release directly.

In order to avoid this difference we provide smaller patches more often now.
We have started already with a subset of about 50 necessary patches.

Even though we get kind support from Alan Cox to get those QAed and integrated,
the pure amount of patches will take at least a couple of weeks to make it in.

This leads to the dilemma, that trying to avoid further differences between
our LVM releases and the stock kernel code would force us into postponing
the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
user base.

In regard to this situation we'ld like to know about your oppinion on
the following request:
is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
status are in vanilla (presumed that we provide them with our release as we
always did before)?

We'll gather your answers for some days and will send the conclusion
to the lists.

Thanks for your support!

-- 

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM 1.0 release decision

[Heinz J. Mauelshagen]

On Fri, May 11, 2001 at 04:06:17PM +0200, Adrian Phillips wrote:
> >>>>> "Heinz" == Heinz J Mauelshagen <Mauelshagen@sistina.com> writes:
> 
>     Heinz> As most of you probably know, we've got criticism a couple
>     Heinz> of weeks ago about our Linux kernel patch policy causing
>     Heinz> the LVM vanilla kernel code to differ from the one we
>     Heinz> release directly.
> 
>     Heinz> In order to avoid this difference we provide smaller
>     Heinz> patches more often now.  We have started already with a
>     Heinz> subset of about 50 necessary patches.
> 
>     Heinz> Even though we get kind support from Alan Cox to get those
>     Heinz> QAed and integrated, the pure amount of patches will take
>     Heinz> at least a couple of weeks to make it in.
> 
> Uh, presumably you're talking 2.4 here.

Yes.

> Seeing as each new 2.2 release
> has a good number of weeks in between it would be not worth delaying
> a LVM release because of that, and the same would seem to go for 2.4
> as well as it becomes more stable.
> 
>     Heinz> This leads to the dilemma, that trying to avoid further
>     Heinz> differences between our LVM releases and the stock kernel
>     Heinz> code would force us into postponing the pending LVM 1.0
>     Heinz> release accordingly which OTOH is incovenient for the LVM
>     Heinz> user base.
> 
> Just release 1.0 with patches to a certain base 2.4.4 and 2.2.19 and
> when 2.4.5 comes out with all the LVM patches init you just mention
> that 2.4.5 has all the relevant patches.

It could be 2.4.5 *or* it could even be multiple 2.4 releases.
Depends on the patch integration time needed.

> 
>     Heinz> In regard to this situation we'ld like to know about your
>     Heinz> oppinion on the following request: is it acceptable to
>     Heinz> release 1.0 soon *before* all patches to reach the 1.0 code
>     Heinz> status are in vanilla (presumed that we provide them with
>     Heinz> our release as we always did before)?
> 
> This is assuming I've actually completely understood what you're
> talking about :-)

You did.
Thanks.

> 
> Sincerely,
> 
> Adrian Phillips
> 
> -- 
> Your mouse has moved.
> Windows NT must be restarted for the change to take effect.
> Reboot now?  [OK]
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM 1.0 release decision

[Jorg de Jong]

"Heinz J. Mauelshagen" wrote:

> This leads to the dilemma, that trying to avoid further differences between
> our LVM releases and the stock kernel code would force us into postponing
> the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
> user base.

In my opinnion the current user base can wait a some more time before what
we now have is labeled 1.0 ( minus the delta between 0.9.1.betaxx).
New users are likely to be scarred off if the find out that they still
have to patch the kernel. 
So my suggestion would be to get the needed patches of to Linus ( and
never again let them acummulate that mutch).
For the user tools I would suggest that you release for each stable kernel
a matching distibution, ie:
kernel 2.4.5 ( 20 lvm patches included), usertools 0.9.2
kernel 2.4.6 ( 45 lvm patches included), usertools 0.9.3
kernel 2.4.7 ( all lvm patches included) usertools 1.0 (plus champain) 

> 
> In regard to this situation we'ld like to know about your oppinion on
> the following request:
> is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
> status are in vanilla (presumed that we provide them with our release as we
> always did before)?
> 
> We'll gather your answers for some days and will send the conclusion
> to the lists.
> 
> Thanks for your support!
> 
> --
> 
> Regards,
> Heinz    -- The LVM Guy --
>

Re: [linux-lvm] LVM 1.0 release decision

[Steven Lembark]

> In regard to this situation we'ld like to know about your oppinion on
> the following request:
> is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
> status are in vanilla (presumed that we provide them with our release as we
> always did before)?
> 
> We'll gather your answers for some days and will send the conclusion
> to the lists.

probably boils down to a marketing issue...

people who already use LVM won't care, we already know how to deal
with this.  new users, however, will feel the pain.  the last thing
we probably want is for first-time users of 1.0 to walk away with a
bad taste from patch/kernel problems.  these people are more likley
to get bit by any patch issues and more likely to either walk away
from LVM or tell other people how much of a hassle it was.  

for my part running the system i'd rather have the "production"
LVM and kernel releases in sync and not have to worry about it.
if i need a beta/inter-version release then i'll deal with the
extra issues.

-- 
 Steven Lembark                                   2930 W. Palmer St.
                                                 Chicago, IL  60647
 lembark@wrkhors.com                                   800-762-1582

Re: [linux-lvm] LVM 1.0 release decision

[Jos� Luis Domingo L�pez]

On Friday, 11 May 2001, at 15:53:11 +0000,
Heinz J. Mauelshagen wrote:

> 
> As most of you probably know, we've got criticism a couple of weeks ago about
> our Linux kernel patch policy causing the LVM vanilla kernel code to differ
> from the one we release directly.
> 
IMHO it is a better long term solution to integrate current LVM into the
mainstream linux kernel base: maybe this causes LVM 1.0 schedule to be
postponed a couple of weeks, but benefits are great:

a) More developers looking at the code, and better and faster integration
with kernel changes (VFS and so on).

b) More people giving LVM a try: perhaps the need for patches and maybe
some tweaking with kernel sources prevented some users from using LVM.

c) Linux kernel's LVM version up to date. Those people trying LVM from
original 2.4.x source tree can get frustated with bugs/functionality of an
old LVM version. Would avoid bug reports on closed bugs.

d) Sooner or later, it has to be done, why wait ?

Greetings, and keep up the good work !

--
Jos� Luis Domingo L�pez
Linux Registered User #189436     Debian GNU/Linux Potato (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => � Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk

Re: [linux-lvm] LVM 1.0 release decision

[Rik van Riel]

On Fri, 11 May 2001, Steven Lembark wrote:

> for my part running the system i'd rather have the "production"
> LVM and kernel releases in sync and not have to worry about it.
> if i need a beta/inter-version release then i'll deal with the
> extra issues.

Agreed.  If the in-kernel LVM cannot be trusted, I really
don't see why Sistina would ever want to associate its name
with something broken?

I think it would be better for everyone (users, Sistina's
corporate image and Linux) to get something stable into the
kernel before sending out the press release ;)

(after all, a version number change is just a one-liner patch
away ;))

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [linux-lvm] LVM 1.0 release decision

[Heinz J. Mauelshagen]

On Sun, May 13, 2001 at 08:48:19PM -0300, Rik van Riel wrote:
> On Fri, 11 May 2001, Steven Lembark wrote:
> 
> > for my part running the system i'd rather have the "production"
> > LVM and kernel releases in sync and not have to worry about it.
> > if i need a beta/inter-version release then i'll deal with the
> > extra issues.
> 
> Agreed.  If the in-kernel LVM cannot be trusted, I really
> don't see why Sistina would ever want to associate its name
> with something broken?

Rik, that's not an issue at all and sorry, it doesn't help either!

With the help of community contributors we *do* provide the most recent
code with as few bugs as possible at www.sistina.com/lvm as we always did.

Everybody could and can get it from there and established LVM users continue
to do it this way.

OTOH we need a lot of time now to get smaller patches into vanilla.

Therefore we kindly asked for community oppinions to help the situation.


Unless a bigger LVM patch to vanilla is accepted, we need to spend a lot of work
on providing those smaller chunks of patches which distracts us a lot from
other work.

Don't tell me that this is all our fault; 
this wouldn't *help* to fasten the process either!

A little trust to accept a bigger patch *and* to sort pending issues
out with the help of the community afterwards is a valid approach IMO to
get faster to the point of an updated vanilla LVM driver than with the
tiny patches approach.

Linus, Alan et al.: maybe you could think about it again and
                    accept one larger LVM patch. Thanks.

> 
> I think it would be better for everyone (users, Sistina's
> corporate image and Linux) to get something stable into the
> kernel before sending out the press release ;)
> 
> (after all, a version number change is just a one-liner patch
> away ;))
> 
> regards,
> 
> Rik
> --
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 
> Send all your spam to aardvark@nl.linux.org (spam digging piggy)
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM 1.0 release decision

[Heinz J. Mauelshagen]

On Fri, May 11, 2001 at 04:13:29PM +0200, Torsten Landschoff wrote:
> On Fri, May 11, 2001 at 03:53:11PM +0000, Heinz J. Mauelshagen wrote:
> > In regard to this situation we'ld like to know about your oppinion on the
> > following request:
> > is it acceptable to release 1.0 soon *before* all patches to reach the 1.0
> > code status are in vanilla (presumed that we provide them with our release as
> > we always did before)?
> 
> My stance would be to do a pre-release of the to-be-1.0 code. Reasons:
> 
> - as you said, it would be good for the user base

Yep.

> - OTOH I would expect the lvm code in the kernel to become a bit 
>   different from what you have now as a matter of the code review.

We are very much interested in your specific requirements here.
Do you have particular recommendations/patches?

> 
> > Thanks for your support!
> 
> Thanks for LVM :-)

You're welcome :-)

> 
> Greetings
> 
> 	Torsten
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM 1.0 release decision

[Chad C. Walstrom]

In message <20010516111903.E11984@sistina.com>, "Heinz J. Mauelshagen" writes:
> A little trust to accept a bigger patch *and* to sort pending issues
> out with the help of the community afterwards is a valid approach
> IMO to get faster to the point of an updated vanilla LVM driver than
> with the tiny patches approach.

Ahh.  OK.  I'm caught up on the situation now. ;-)  So Linus et. al.
are jumpy about a large patch to the kernel.  Not surprising.  Also
very frustrating for the end-user to know that tested and successful
code cannot be incorporated into the mainstream kernel en`masse,
rather it must be added piecemeal.  

With each version of LVM, bugs were fixed, interoperability was
improved, and stability was increased.  Will piecemealing these
changes into the "kernel proper" sacrifice these improvements for the
sake of trust?

I can appreciate the caution that Linus et. al. would prefer to
maintain, but if partial solutions break things just to get to the end
of the race, I'm not sure it's worth strapping on the running shoes.

I would second Heinz' view.

If it doesn't go your way, Heinz and crew, we appreciate all the hard
work you're doing.  When all is said and done, take some time off. ;-)
Grab a beer, some sun, and a much deserved vacation.

--
Chad Walstrom <chewie@wookimus.net>                 | a.k.a. ^chewie
http://www.wookimus.net/                            | s.k.a. gunnarr
Key fingerprint = B4AB D627 9CBD 687E 7A31  1950 0CC7 0B18 206C 5AFD

Re: [linux-lvm] LVM 1.0 release decision

[Rik van Riel]

On Wed, 16 May 2001, Heinz J. Mauelshagen wrote:

> Linus, Alan et al.: maybe you could think about it again and
>                     accept one larger LVM patch. Thanks.

I'm all for it right now. I'm running LVM on practically all my
machines and would really like to have the latest bugfixes in
my kernel ;)

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [linux-lvm] LVM 1.0 release decision

[Steven Lembark]

> OTOH we need a lot of time now to get smaller patches into vanilla.
> 
> Therefore we kindly asked for community oppinions to help the situation.
> 
> Unless a bigger LVM patch to vanilla is accepted, we need to spend a lot of work
> on providing those smaller chunks of patches which distracts us a lot from
> other work.

unless the smaller patches really break something then let the
vanilla system fall behind.  

-- 
 Steven Lembark                                   2930 W. Palmer St.
                                                 Chicago, IL  60647
 lembark@wrkhors.com                                   800-762-1582

Re: [linux-lvm] LVM 1.0 release decision

[Steven Lembark]

> I'm all for it right now. I'm running LVM on practically all my
> machines and would really like to have the latest bugfixes in
> my kernel ;)

then grab the patches and apply them.  the main issue seems to 
be the rate at which LVM patches migrate into the stock distribution.
if you are running that much LVM it's likely that you already know
how to patch things to handle LVM in the first place.

-- 
 Steven Lembark                                   2930 W. Palmer St.
                                                 Chicago, IL  60647
 lembark@wrkhors.com                                   800-762-1582

Re: [linux-lvm] LVM 1.0 release decision

[Harald Milz]

In article <wxxoft055j0.fsf@fjorir.ifi.uio.no>, Terje Kvernes <terjekv@math.uio.no> wrote:
>   this reminds me of XFS to be honest -- and that annoys me a great
>   deal. I want to test XFS, but currently I can't. because after LVM
>   and ReiserFS are patched (they pull rank :), the XFS-patches botch
>   badly. and they're far from in sync with current kernels.

That seems to depend. I recently patched 2.4.2-SuSE (not famous for being a
vanilla kernel, and containing LVM and Reiserfs) with the 2.4.2 XFS patch,
and just got 1 reject in a Makefile which I could safely ignore because the
SuSE kernel already contained that patch. And guess what: XFS and Reiserfs
work nicely together with LVM on the same machine!

-- 
Harald Milz           |     hm@linux-magazin.de     | All generalizations
Linux Magazin         | phone  +49 (0) 89 993411-20 | are shit!
Stefan-George-Ring 24 | fax    +49 (0) 89 993411-99 | 
D-81929 Muenchen      | http://www.linux-magazin.de | 

Re: [linux-lvm] LVM 1.0 release decision

[Terje Kvernes]

Harald Milz <hmilz@linux-magazin.de> writes:

> In article <wxxoft055j0.fsf@fjorir.ifi.uio.no>, Terje Kvernes <terjekv@math.uio.no> wrote:
>
> > this reminds me of XFS to be honest -- and that annoys me a great
> > deal. I want to test XFS, but currently I can't. because after LVM
> > and ReiserFS are patched (they pull rank :), the XFS-patches botch
> > badly. and they're far from in sync with current kernels.
> 
> That seems to depend. I recently patched 2.4.2-SuSE (not famous for
> being a vanilla kernel, and containing LVM and Reiserfs) with the
> 2.4.2 XFS patch, and just got 1 reject in a Makefile which I could
> safely ignore because the SuSE kernel already contained that patch.

  yes, well. I often want the latest kernel (down to -ac). try
  grabbing a totally vanilla kernel and patching it up. I've tried a
  few times but not bothered in the end. especially with the
  knfsd-patch to ReiserFS. 

> And guess what: XFS and Reiserfs work nicely together with LVM on
> the same machine!

  goodie. that's something I'll need to test a new 600GB raid system
  soonish. I certainly hope it'll be doable, and easier than the last
  two attempts... another worry is that if someone (XFS / ReiserFS /
  LVM or someone else) comes up with a critical fix, how easy will it
  be to make the new kernel again?

  it's not enough that I can get _one_ kernel to work, I need to be
  able to get new kernels to work. within a day or so if it's anything
  like ptrace with friends.
  
  LVM isn't bad in this manner at all. it's just not "perfect". I'm
  very impressed with the way the LVM-crew have handled the kernel
  issue, and the criticism regarding the mailinglist and everything...
  the only thing left is that LVM is the key for a lot of mainstream
  server usage. there are several filesystems that can be used, but
  there isn't much to take the place of LVM.

-- 
Terje