Re: Linux v2.5.42

Re: Linux v2.5.42

[Mark Peloquin]

On 2002-10-12 13:32:33, Christoph Hellwig wrote:
> > On Fri, Oct 11, 2002 at 09:59:58PM -0700, Linus Torvalds wrote:
> > PS: NOTE - I'm not going to merge either EVMS or LVM2 right now > as 
>things
> > stand.  I'm not using any kind of volume management personally, so > > I 
>just
> > don't have the background or inclination to walk through the > patches 
>and
> > make that kind of decision. My non-scientific opinion is that it > looks 
> > like the EVMS code is going to be merged, but ..
> > > Alan, Jens, Christoph, others - this is going to be an area where > > 
>I need
> > input from people I know, and preferably also help merging. I've > been 
> > happy to see the EVMS patches being discussed on linux-kernel, and > > I 
>just > wanted to let people know that this needs outside help.

>I don't think the work to get EVMS in shape can be done in time > (feel
>free to preove me wrong..).

Should EVMS be included, the team will make it our top priority to resolve 
the disputed design issues. If the ruling should be that some of our design 
decisions must change, so be it, we will comply. Certainly some changes can 
not be done by the 20th or 31st, however I feel the team can handle most 
changes before 2.6 ships.

>The problem in my eyes is that large
>parts of what evms does should be in the higher layers, i.e. the
>block layer, but they implement their own new layer as the consumer > of
>those.  i.e. instead of using the generic block layer structures to
>present a volume/device they use their own,

More accurately, we do use generic block layers structures to present 
volumes that are visible to the user/system.

>private structures that
>need hacks to get the access right (pass-through ioctls) and need
>constant resyncing with the native structures in the case where we
>have both (the lowest layer).

The point of contention is that EVMS does not provide generic access (block 
layer operations) to the components that make up the volume, but only to the 
user/system accessible volumes themselves. EVMS consumes (primarily disk) 
devices and produces volumes. The intermediate points are abstracted by the 
volume manager.

>IMHO we should try to get a common
>userspace API in first, then implement the missing functionality for
>properly interaction of voulme managers at the block layer.  After
>that EVMS would just be a set of coulme mangment drivers + a library
>of common functionality.

>Doing that higher level work will take some time to get right, and the
>current EVMS API seems unsuitable for me, it contains lots of very#
>strange APIs that need rework.  Merging EVMS now for 2.6 means that
>we'll have to keep those strange APIs around, and have to maintain
>backwards-compatiblity.

I guess it comes down to the point of whether the block layer should evolve 
to also handle volume management generically, or whether volume management 
is separate component that utilizes and works with the block layer.

Linus, if you feel that volume management and the block layer can and should 
be separate components that work together, then EVMS is ready today, and at 
least functionally, could be a pretty good starting point. As a separate 
component, only the EVMS tools would have to know or care of the new EVMS 
APIs. The volumes EVMS produces, being standard block devices, interface, 
interact, and operate as any other block device does today.

Mark

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: Linux v2.5.42

[Alan Cox]

On Sat, 2002-10-12 at 18:14, Mark Peloquin wrote:
> Should EVMS be included, the team will make it our top priority to resolve 
> the disputed design issues. If the ruling should be that some of our design 
> decisions must change, so be it, we will comply. Certainly some changes can 
> not be done by the 20th or 31st, however I feel the team can handle most 
> changes before 2.6 ships.

Thats good to hear. Right now the debate appears to be - "users: please
add EVMS" "hackers: oh my god no" - so you got the feature set right it
seems

Re: Linux v2.5.42

[jbradford]

> > Should EVMS be included, the team will make it our top priority to resolve 
> > the disputed design issues. If the ruling should be that some of our design 
> > decisions must change, so be it, we will comply. Certainly some changes can 
> > not be done by the 20th or 31st, however I feel the team can handle most 
> > changes before 2.6 ships.
> 
> Thats good to hear. Right now the debate appears to be - "users: please
> add EVMS" "hackers: oh my god no" - so you got the feature set right it
> seems

Obvious point:

* Linus can always thaw the tree after 31st just for one addition, if
something _really_ needs to be added for 2.6

John.

Re: [Evms-devel] Re: Linux v2.5.42

[Michael Clark]

On 10/13/02 01:14, Mark Peloquin wrote:
> On 2002-10-12 13:32:33, Christoph Hellwig wrote:
>
>> The problem in my eyes is that large
>> parts of what evms does should be in the higher layers, i.e. the
>> block layer, but they implement their own new layer as the consumer > of
>> those.  i.e. instead of using the generic block layer structures to
>> present a volume/device they use their own,
> 
> 
> More accurately, we do use generic block layers structures to present 
> volumes that are visible to the user/system.

Exactly. I think Christoph is comparing it to the original md
architecture thich was more of an evolutionary design on the existing
block layer - it is merely an artifact of this that intermediary
devices were present (and consuming minors) - in a well architected
volume manager, this is not necessary or desirable - not presenting
the intermediary devices is IMHO also a saftey feature preventing
access to devices that shouldn't be accessed.

>> private structures that
>> need hacks to get the access right (pass-through ioctls) and need
>> constant resyncing with the native structures in the case where we
>> have both (the lowest layer).
> 
> 
> The point of contention is that EVMS does not provide generic access 
> (block layer operations) to the components that make up the volume, but 
> only to the user/system accessible volumes themselves. EVMS consumes 
> (primarily disk) devices and produces volumes. The intermediate points 
> are abstracted by the volume manager.

Yes, considering the abstraction (and the futureproofing this provides),
it would not make sense to bind these logical nodes to the orthogonal
block layer - which would probably also make maintenance more complex
in the future. I guess one of the advantages of the EVMS approach
is the ability for the core code to fit more easily with less changes
into kernels with differing block layers (2.4,2.5,future).

~mc

Re: Linux v2.5.42

[Christoph Hellwig]

On Sat, Oct 12, 2002 at 12:14:25PM -0500, Mark Peloquin wrote:
> I guess it comes down to the point of whether the block layer should evolve 
> to also handle volume management generically, or whether volume management 
> is separate component that utilizes and works with the block layer.
> 
> Linus, if you feel that volume management and the block layer can and should 
> be separate components that work together, then EVMS is ready today,

No, it's not.  Even if this design stands the code still has many issues.
Neverless even if we don't want separate representations of intermediate
volmes and topmost volumes, the voulme managment should not be part of
a driver but higher leve, i.e. separated out from the evms common library
code.

Re: [Evms-devel] Re: Linux v2.5.42

[Christoph Hellwig]

On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote:
> Exactly. I think Christoph is comparing it to the original md
> architecture thich was more of an evolutionary design on the existing
> block layer

No, I do not.  MD is in _no_ ways a volume managment framwork but just
a few drivers that share common code.  That's somethig entirely different.

> it is merely an artifact of this that intermediary
> devices were present (and consuming minors)

I don not think cosumes minors is a valid design criteria for designing
an inkernel framework.

> in a well architected
> volume manager, this is not necessary or desirable - not presenting
> the intermediary devices is IMHO also a saftey feature preventing
> access to devices that shouldn't be accessed.

Please explain why they shouldn't be accessed.  And following your
argumentation tell me why you haven't submitted a patch to Linus
yet to disallow direct access to block devices that are in use
by a filesystem.

> Yes, considering the abstraction (and the futureproofing this provides),
> it would not make sense to bind these logical nodes to the orthogonal
> block layer - which would probably also make maintenance more complex
> in the future.

Please explain the added complexity in detail.  In fact it does remove
complexity by having a standard set of object to work on, removing the
need for code, data and data structure duplication.  Before answering
this mail I'd suggest you take a look at ldev_mgr.c in the evms
tree in detail (and yes, that file is horribly broken implementation-wise,
but this discussion is about the complexity it adds)

> I guess one of the advantages of the EVMS approach
> is the ability for the core code to fit more easily with less changes
> into kernels with differing block layers (2.4,2.5,future).

This argument is NIL if the infrastructure is part of exactly that
evolving block layer.  You might have noticed that kernel code
compatility to other releases is not really a criteria for the
linux kernel development, btw..

Re: [Evms-devel] Re: Linux v2.5.42

[Michael Clark]

On 10/13/02 21:49, Christoph Hellwig wrote:
> On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote:
> 
>>Exactly. I think Christoph is comparing it to the original md
>>architecture thich was more of an evolutionary design on the existing
>>block layer
> 
> 
> No, I do not.  MD is in _no_ ways a volume managment framwork but just
> a few drivers that share common code.  That's somethig entirely different.

So why then the requirement that internal remapping layers be
implemented as block devices?

>>it is merely an artifact of this that intermediary
>>devices were present (and consuming minors)
> 
> 
> I don not think cosumes minors is a valid design criteria for designing
> an inkernel framework.

Neither is implementing an internal logical remapping layer as a
block device just so you can do an ioctl directly to it.

>>in a well architected
>>volume manager, this is not necessary or desirable - not presenting
>>the intermediary devices is IMHO also a saftey feature preventing
>>access to devices that shouldn't be accessed.
> 
> 
> Please explain why they shouldn't be accessed.  And following your

I think the point is really explaining why they _should_ be accessed.
If there is some valid reason other than having something you
can do an ioctl on.

> argumentation tell me why you haven't submitted a patch to Linus
> yet to disallow direct access to block devices that are in use
> by a filesystem.

I think the issue here is an md block device in use by another md block
device. Possbily becuase md's design precludes this (a design artifact)
(ie. md tools need access to the intermediary devices - users don't).

>>Yes, considering the abstraction (and the futureproofing this provides),
>>it would not make sense to bind these logical nodes to the orthogonal
>>block layer - which would probably also make maintenance more complex
>>in the future.
> 
> 
> Please explain the added complexity in detail.  In fact it does remove
> complexity by having a standard set of object to work on, removing the
> need for code, data and data structure duplication.  Before answering
> this mail I'd suggest you take a look at ldev_mgr.c in the evms
> tree in detail (and yes, that file is horribly broken implementation-wise,
> but this discussion is about the complexity it adds)

Yes, but the block device encapsulation here removes the need for plugins
to be implemented as block devices ie. removing complexity elsewhere.
I must admit to not being an expert on the block layer - but wouldn't
your suggesed approach mean intermediary layers would each have a
request queue and other unneeded stuff - if so, is this desirable?
(although i suspect i'm likely to be proved wrong - but i'm sure
there are issues with where you want your request queues - only on
the block devices exposed as volumes).

I still can't see the rationale of implementing instances of intermediary
remapping layers as block devices. Since you are the one that is objecting
to the current approach, the owness is on you to prove why an alternative
is needed.

>>I guess one of the advantages of the EVMS approach
>>is the ability for the core code to fit more easily with less changes
>>into kernels with differing block layers (2.4,2.5,future).
> 
> 
> This argument is NIL if the infrastructure is part of exactly that
> evolving block layer.  You might have noticed that kernel code
> compatility to other releases is not really a criteria for the
> linux kernel development, btw..

I agree, maybe this would be worth doing for 2.7/2.8. In the meatime
do you think this would be feasible? - you are basically suggesting
a complete rewrite (or do you think you can do the rewrite to IBM's
satisfaction before the freeze ie. in the eternal linux kernel way,
you want it you write it ;). Me, i'm happy with the current approach
- but of course, i'm only a user ;).

~mc

Re: [Evms-devel] Re: Linux v2.5.42

[Christoph Hellwig]

On Sun, Oct 13, 2002 at 11:16:24PM +0800, Michael Clark wrote:
> On 10/13/02 21:49, Christoph Hellwig wrote:
> > On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote:
> > 
> >>Exactly. I think Christoph is comparing it to the original md
> >>architecture thich was more of an evolutionary design on the existing
> >>block layer
> > 
> > 
> > No, I do not.  MD is in _no_ ways a volume managment framwork but just
> > a few drivers that share common code.  That's somethig entirely different.
> 
> So why then the requirement that internal remapping layers be
> implemented as block devices?

I don't care how a single remapping layers is implemented.  I want
the common Voulme managment API work on public nodes.

> Neither is implementing an internal logical remapping layer as a
> block device just so you can do an ioctl directly to it.

Not without hacks. 

> I think the point is really explaining why they _should_ be accessed.
> If there is some valid reason other than having something you
> can do an ioctl on.

Because that

a) removes hacks like the EVMS pass-though
b) allows userspace to easily access it through read/write

> 
> > argumentation tell me why you haven't submitted a patch to Linus
> > yet to disallow direct access to block devices that are in use
> > by a filesystem.
> 
> I think the issue here is an md block device in use by another md block
> device. Possbily becuase md's design precludes this (a design artifact)
> (ie. md tools need access to the intermediary devices - users don't).

I'm not talksing about MD here.  Why do you want to disallow people
using a device just it has another layer above it.  E.g. write a change
to the ondisk structures (setting a flag, etcc..) is most logically
expressed by simple, O_DIRECT write to the actual device.


> Yes, but the block device encapsulation here removes the need for plugins
> to be implemented as block devices ie. removing complexity elsewhere.
> I must admit to not being an expert on the block layer - but wouldn't
> your suggesed approach mean intermediary layers would each have a
> request queue

It _coukd_ have a request queue, yes.

> and other unneeded stuff - if so, is this desirable?

What unneeded stuff?  block device state contains no state relevant
to userspace access.

> > This argument is NIL if the infrastructure is part of exactly that
> > evolving block layer.  You might have noticed that kernel code
> > compatility to other releases is not really a criteria for the
> > linux kernel development, btw..
> 
> I agree, maybe this would be worth doing for 2.7/2.8.

Yes.

> In the meatime
> do you think this would be feasible? - you are basically suggesting
> a complete rewrite

Exactly.

> (or do you think you can do the rewrite to IBM's
> satisfaction before the freeze ie. in the eternal linux kernel way,
> you want it you write it ;). Me, i'm happy with the current approach
> - but of course, i'm only a user ;).

_I_ don't want to get EVMS in, sorry.  I _do_ want a proper volume
managment framework, but I can live with it not beeing in before 2.8.

Re: Linux v2.5.42

[Brian Jackson]

Christoph Hellwig writes: 

> On Sun, Oct 13, 2002 at 11:16:24PM +0800, Michael Clark wrote:
>> On 10/13/02 21:49, Christoph Hellwig wrote:
>> > On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote:
>> > 
>> >>Exactly. I think Christoph is comparing it to the original md
>> >>architecture thich was more of an evolutionary design on the existing
>> >>block layer
>> > 
>> > 
>> > No, I do not.  MD is in _no_ ways a volume managment framwork but just
>> > a few drivers that share common code.  That's somethig entirely different. 
>> 
>> So why then the requirement that internal remapping layers be
>> implemented as block devices?
> 
> I don't care how a single remapping layers is implemented.  I want
> the common Voulme managment API work on public nodes. 
> 
>> Neither is implementing an internal logical remapping layer as a
>> block device just so you can do an ioctl directly to it.
> 
> Not without hacks.  
> 
>> I think the point is really explaining why they _should_ be accessed.
>> If there is some valid reason other than having something you
>> can do an ioctl on.
> 
> Because that 
> 
> a) removes hacks like the EVMS pass-though
> b) allows userspace to easily access it through read/write 
> 
>> 
>> > argumentation tell me why you haven't submitted a patch to Linus
>> > yet to disallow direct access to block devices that are in use
>> > by a filesystem. 
>> 
>> I think the issue here is an md block device in use by another md block
>> device. Possbily becuase md's design precludes this (a design artifact)
>> (ie. md tools need access to the intermediary devices - users don't).
> 
> I'm not talksing about MD here.  Why do you want to disallow people
> using a device just it has another layer above it.  E.g. write a change
> to the ondisk structures (setting a flag, etcc..) is most logically
> expressed by simple, O_DIRECT write to the actual device. 
> 
> 
>> Yes, but the block device encapsulation here removes the need for plugins
>> to be implemented as block devices ie. removing complexity elsewhere.
>> I must admit to not being an expert on the block layer - but wouldn't
>> your suggesed approach mean intermediary layers would each have a
>> request queue
> 
> It _coukd_ have a request queue, yes. 
> 
>> and other unneeded stuff - if so, is this desirable?
> 
> What unneeded stuff?  block device state contains no state relevant
> to userspace access. 
> 
>> > This argument is NIL if the infrastructure is part of exactly that
>> > evolving block layer.  You might have noticed that kernel code
>> > compatility to other releases is not really a criteria for the
>> > linux kernel development, btw.. 
>> 
>> I agree, maybe this would be worth doing for 2.7/2.8.
> 
> Yes. 
> 
>> In the meatime
>> do you think this would be feasible? - you are basically suggesting
>> a complete rewrite
> 
> Exactly. 
> 
>> (or do you think you can do the rewrite to IBM's
>> satisfaction before the freeze ie. in the eternal linux kernel way,
>> you want it you write it ;). Me, i'm happy with the current approach
>> - but of course, i'm only a user ;).
> 
> _I_ don't want to get EVMS in, sorry.  I _do_ want a proper volume
> managment framework, but I can live with it not beeing in before 2.8. 
> 

Good for you. Most people can't/won't wait for it. They will see that linux 
doesn't have a key feature for enterprises, and say that linux still isn't 
mature enough for them and at best only use linux on some dinky little 
webservers, like it has been used in the past. There isn't a whole lot of 
that market left. If we want to move forward and offer something to a 
broader base of companies, we need features like this included. 

 --Brian Jackson 

p.s. Maybe you could keep your replies to constructive criticism, instead of 
just dogging EVMS. Some people actually do want linux to improve. 

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
 

Re: [Evms-devel] Re: Linux v2.5.42

[Michael Clark]

On 10/13/02 23:35, Christoph Hellwig wrote:
> _I_ don't want to get EVMS in, sorry.

You've made your intentions crystal clear. Lucky you're not the
one you decides. At the end of the day it is just another 'driver'
and I don't think it's fair to place a higher benchmark of quality
on EVMS than all the other drivers in the kernel (although your
criticism does serve as a good way of disguising your motives of
blocking its inclusion).

We all know you 'you can't please all of the people all of the time'
and its always the dissenters who have the loudest voice.

 > I _do_ want a proper volume managment framework, but I can live with
 > it not beeing in before 2.8.

Some of us have large arrays and SANs where the absence a volume
manager is a big thing. I'm glad to see the distros picking it up
- i guess they have customers who need this sort of stuff.

How about feedback from other kernel developers on EVMS. Does anyone
think 'its good enough for inclusion now as long as a few cleanups
are done after the freeze'?

~mc

Re: Linux v2.5.42

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Sun, 2002-10-13 at 18:11, Brian Jackson wrote:

> p.s. Maybe you could keep your replies to constructive criticism, instead of 
> just dogging EVMS. Some people actually do want linux to improve. 

In case you missed is: EVMS is not the only way you can do volume
management in 2.5... and Christoph is pointing out valid design flaws
(and serious code bugs) in EVMS. Code bugs you can fix after merge;
design flaws should at least be discussed before merging in my opinion.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux v2.5.42

[Brian Jackson]

Arjan van de Ven writes: 

> On Sun, 2002-10-13 at 18:11, Brian Jackson wrote: 
> 
>> p.s. Maybe you could keep your replies to constructive criticism, instead of 
>> just dogging EVMS. Some people actually do want linux to improve. 
> 
> In case you missed is: EVMS is not the only way you can do volume
> management in 2.5... and Christoph is pointing out valid design flaws
> (and serious code bugs) in EVMS. Code bugs you can fix after merge;
> design flaws should at least be discussed before merging in my opinion. 
> 

Yes I do realize that, but I think EVMS offers more in the long run than any 
of the others. I don't mean to speak ill of Christoph(he has done some very 
good work in the past, and I think he is very talented), In fact, I thought 
he handled the problems with EVMS very well at first(pointing out problems, 
etc.), but then as the thread went on you could tell he was just taking it 
more and more personally(for whatever reasons), and we all know that doesn't 
help getting things done, especially not with a deadline looming. I don't 
know as much as I should about all of this considering I am opening my mouth 
on the subject, but it seems that something needs to be done soon one way or 
another. 

 --Brian 

Re: [Evms-devel] Re: Linux v2.5.42

[Alexander Viro]

On Mon, 14 Oct 2002, Michael Clark wrote:

> Some of us have large arrays and SANs where the absence a volume
> manager is a big thing. I'm glad to see the distros picking it up
> - i guess they have customers who need this sort of stuff.
> 
> How about feedback from other kernel developers on EVMS. Does anyone
> think 'its good enough for inclusion now as long as a few cleanups
> are done after the freeze'?


	Mostly those who won't have to clean up the mess afterwards.
For the record, my vote is "not ready".

	There are good chunks, no arguments about that.  However, IMNSHO
we will be better off if we gradually pick the pieces that make sense
and integrate them into the system.  As it is, wholesale merge would cost
us too much half a year down the road.

	I have seen major subsystem rewrites.  I have done several myself.
I have also done more than a bit of wading through "yet another drivers".
EVMS in its current state shows a lot of signs promising very painful
work on cleanups and intergration.  "Few cleanups after the freeze" doesn't
come anywhere near the impression I'm getting from it and I would bet a lot
on that particular impression.

Re: [Evms-devel] Re: Linux v2.5.42

[Michael Clark]

On 10/14/02 01:10, Alexander Viro wrote:
> 
> On Mon, 14 Oct 2002, Michael Clark wrote:
> 
> 
>>Some of us have large arrays and SANs where the absence a volume
>>manager is a big thing. I'm glad to see the distros picking it up
>>- i guess they have customers who need this sort of stuff.
>>
>>How about feedback from other kernel developers on EVMS. Does anyone
>>think 'its good enough for inclusion now as long as a few cleanups
>>are done after the freeze'?
> 
> 	Mostly those who won't have to clean up the mess afterwards.
> For the record, my vote is "not ready".
> 
> 	There are good chunks, no arguments about that.  However, IMNSHO
> we will be better off if we gradually pick the pieces that make sense
> and integrate them into the system.  As it is, wholesale merge would cost
> us too much half a year down the road.

I guess it boils down to differentiation between architectural flaws
and more trivial code cleanup. I guess the thing that drew me to Christoph's
particular criticism was whether or not it is a flaw or a feature for
remapping layers to just be remapping layers and not also block devices.

If it is the concensus that remapping layers should also be block devices
then i concede. Although clearly there needs to be a little more reason
than having a device node to do an ioctl on.

> 	I have seen major subsystem rewrites.  I have done several myself.
> I have also done more than a bit of wading through "yet another drivers".
> EVMS in its current state shows a lot of signs promising very painful
> work on cleanups and intergration.  "Few cleanups after the freeze" doesn't
> come anywhere near the impression I'm getting from it and I would bet a lot
> on that particular impression.

Okay. It's just not clear which criticism are of the trival post merge
code cleanup kind, which are true architectural problems, and which are
singly held opinions on architectural requirements.

Can we have some concensus on whether intermediate remapping layers also need
to be exposed as block devices as this requiement would have a large impact
on the code.

 From the discussion so far:

Pros
* Simplify ioctl routing to plugins

Cons
* Chew up a minor
* Get a block device we don't need or want (ie. we can still easily
   directly access the underlying physical block devices)
* loose purely logical remapping abstraction in plugins
* Complicate mapping of request queues to devices (ie. shouldn't only
   the top level volume device and the underlying physical devices need
   request queues)

~mc

Re: Linux v2.5.42

[Robert Love]

On Sun, 2002-10-13 at 12:11, Brian Jackson wrote:

> Good for you. Most people can't/won't wait for it. They will see that
> linux  doesn't have a key feature for enterprises, and say that linux
> still isn't mature enough for them and at best only use linux on some
> dinky little webservers, like it has been used in the past. There
> isn't a whole lot of that market left. If we want to move forward and
> offer something to a broader base of companies, we need features like
> this included. 

s/Most people/Most enterprise people/

And this is really entirely the wrong attitude to take.  "Linux does not
have volume management" and "High-end Linux applications need volume
management" do not logically imply "we need to merge EVMS."

You need to fix the issues Christoph and others raised and you need to
work within the system.  I won't cry if EVMS is not merged.

	Robert Love

Re: Linux v2.5.42

[Brian Jackson]

Robert Love writes: 

> On Sun, 2002-10-13 at 12:11, Brian Jackson wrote: 
> 
>> Good for you. Most people can't/won't wait for it. They will see that
>> linux  doesn't have a key feature for enterprises, and say that linux
>> still isn't mature enough for them and at best only use linux on some
>> dinky little webservers, like it has been used in the past. There
>> isn't a whole lot of that market left. If we want to move forward and
>> offer something to a broader base of companies, we need features like
>> this included. 
> 
> s/Most people/Most enterprise people/ 
> 
> And this is really entirely the wrong attitude to take.  "Linux does not
> have volume management" and "High-end Linux applications need volume
> management" do not logically imply "we need to merge EVMS." 
> 
> You need to fix the issues Christoph and others raised and you need to
> work within the system.  I won't cry if EVMS is not merged. 
> 

Just for clarification I have nothing to do with EVMS, other than I think it 
would be a good addition. I don't want anybody to get the idea that they are 
as unprofessional as me. 

 --Brian 

> 	Robert Love 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
 

Re: Linux v2.5.42

[Rik van Riel]

On Sun, 13 Oct 2002, Mark Hahn wrote:

> > Yes I do realize that, but I think EVMS offers more in the long run than any
> > of the others.
>
> not to put too find a point on it, but IBM has their own goals. for
> instance, some part of EVMS design is motivated by IBM's political
> desire to permit its bank customers, who have horrible old OS/2 systems,
> to transparently use OS/2 volumes.  it's not as if IBM couldn't provide
> a simple, user-level migration tool.

You don't need a migration tool.

All you need is:

1) a kernel level driver that can map devices, ie. a device mapper

2) user space tools that can parse the volume metadata and tell the
   kernel how to map each chunk at initialisation or mount time

You don't need a flying circus in kernel space.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: Linux v2.5.42

[Mark Hahn]

> Yes I do realize that, but I think EVMS offers more in the long run than any 
> of the others.

not to put too find a point on it, but IBM has their own goals.
for instance, some part of EVMS design is motivated by IBM's political
desire to permit its bank customers, who have horrible old OS/2 systems,
to transparently use OS/2 volumes.  it's not as if IBM couldn't provide
a simple, user-level migration tool.  it's not as if the Linux community
is going to rush out and say "let's all start use OS/2 volumes everywhere!"

using Linux to make your customers happy is great; 
the issue is whether it deforms Linux in general to be shaped 
by non-shared priorities.  yes, I'm a crank, and yes, I'm bothered 
by other IBM influences, such as their fixation with performance of 
broken platforms like Profusion, or tuning for NUMA.

the best part of Linux is its willingness to throw out old designs;
a big system like EVMS has its own resistance to such redesign.

Re: Linux v2.5.42

[Andrew Morton]

Mark Hahn wrote:
> 
> I'm bothered by other IBM influences, such as their fixation with
> performance of broken platforms like Profusion, or tuning for NUMA.

Actually it's rather useful to have these platforms around.  Because
if you fix a problem on profusion and NUMA-Q, it's really, really fixed
for other hardware...

They show up races and lock contention like crazy.

Re: Linux v2.5.42

[Bernd Eckenfels]

In article <Pine.LNX.4.33.0210131545510.17395-100000@coffee.psychology.mcmaster.ca> you wrote:
> for instance, some part of EVMS design is motivated by IBM's political
> desire to permit its bank customers, who have horrible old OS/2 systems,
> to transparently use OS/2 volumes.

Some parts? I guess it is one module. What is wrong with this. Support for
non standard partition and slice types is currently cluttering up the kernel
source. I will be more than happy to see this in a EVMS module.

Greetings
Bernd

Re: Linux v2.5.42

[Sean Neakums]

commence  Rik van Riel quotation:

> All you need is:
>
> 1) a kernel level driver that can map devices, ie. a device mapper
>
> 2) user space tools that can parse the volume metadata and tell the
>    kernel how to map each chunk at initialisation or mount time
>
> You don't need a flying circus in kernel space.

I don't know my arse from my elbow when it comes to kernel design and
coding issues, but my chimpanzee brain really likes this aspect of the
LVM2/dm combination.

-- 
 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <sneakums@zork.net>     |      answers a prison for oneself.
 \                          |

Re: Linux v2.5.42

[Rob Landley]

On Saturday 12 October 2002 03:37 pm, jbradford@dial.pipex.com wrote:

> Obvious point:
>
> * Linus can always thaw the tree after 31st just for one addition, if
> something _really_ needs to be added for 2.6
>
> John.

New entry to the famous last words list: "just one addition".

Um, no please?  Can of worms?  Bad Thing (tm)?

Rob

(I'd much rather have to patch my kernel to get a feature than go through 
another nine months of "2.6-pre37-pre2-we_really_mean_it_this_time-ac4".
I don't care if my system won't BOOT without it, everybody has _something_ 
they can't live without...)

Re: [Evms-devel] Re: Linux v2.5.42

[Andreas Dilger]

On Oct 13, 2002  13:46 -0400, Robert Love wrote:
> And this is really entirely the wrong attitude to take.  "Linux does not
> have volume management" and "High-end Linux applications need volume
> management" do not logically imply "we need to merge EVMS."

Well, I think the attitude is more like "I've never used volume
management, and high-end systems use volume management, therefore only
high end systems will benefit from volume management".

It's like Fortran programmers saying "I've gotten by with only static
memory allocation all of these years, do dynamic memory allocation in
C is just useless".  (Yes, I know "them's fightin' words" ;-)

The truth is that once you've gotten used to the LVM paradigm, going
back to "partitions" sucks, a lot.  Not having to over-allocate huge
gobs of disk to partitions because you don't want to backup, reformat, 
restore, repeat each time you manage to run out of space in a partition
is a big win, whether you're administering 1 disk drive or 1000.

Being able to create temporary volumes for whatever need strikes you,
increasing the amount of free space in your filesystem while it's
mounted, that's a big win in my books, even on a laptop (maybe even
_especially_ on a laptop where you can't easily add another disk).

Maybe there are some warts in EVMS, but that doesn't mean we don't
need it (or equivalent) in Linux.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: [Evms-devel] Re: Linux v2.5.42

[Andreas Dilger]

On Oct 14, 2002  01:41 +0800, Michael Clark wrote:
> Can we have some concensus on whether intermediate remapping layers also 
> need to be exposed as block devices as this requiement would have a large
> impact on the code.
> 
> From the discussion so far:
> 
> Pros
> * Simplify ioctl routing to plugins
> 
> Cons
> * Chew up a minor
> * Get a block device we don't need or want (ie. we can still easily
>   directly access the underlying physical block devices)
> * lose purely logical remapping abstraction in plugins
> * Complicate mapping of request queues to devices (ie. shouldn't only
>   the top level volume device and the underlying physical devices need
>   request queues)

I never did get a clear understanding why Christoph wants access to
"intermediate" block devices from EVMS, except for the ioctl issue.
Granted, it _may_ be more "pure" to keep within the current block device
paradigm for each internal stacking layer, or whatever.  If AV wants
it implemented differently, then do it, I say.  But, that said, the
fact that each intermediate layer _could_ be considered a block device
does not mean that it makes sense to allow user-space access to these
intermediate layers.

Why on earth would I want to start reading from or writing to a block
device which is part of a RAID 5 volume which is chunked into 16MB
logical extents for a volume which is part of a snapshot of some
totally different volume?  Yes, in some strange recovery scenario, I
might want to 'dd' the underlying disks somewhere else for backup, but
otherwise the only other thing I can possibly do is corrupt my data
by mistake.

Don't get me wrong, I'm all for giving people enough rope to shoot
themselves in the foot, but I'd rather have /proc/partitions show me
"you have 10 volumes" than "you have these 500 partial volumes that
aren't really useful by themselves - good luck finding which one
currently isn't in use for the filesystem you need to make".

It's like "ls -l" showing you each and every block that makes up a file,
or "ps aux" listing the address of each chunk of RAM that a process has
allocated.  Even better (Al will hate this one), it's like processes
being able to read(2) and write(2) directory "files", ugh.  Sure, in
some strange context it might be useful to have this information (and
there are definitely tools which will let you know it and work directly
on the raw bits), but in 99.9999% of cases it is just an accident
waiting to happen, a waste of time to see this much detail, and confusion
for users.

Ted will recall an incident at VA where an intern mke2fs'd part of an
MD RAID device that made up Sourceforge, because he couldn't see it
mounted anywhere, and thought it wasn't in use.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: [Evms-devel] Re: Linux v2.5.42

[Andreas Dilger]

On Oct 13, 2002  15:58 -0400, Mark Hahn wrote:
> > Yes I do realize that, but I think EVMS offers more in the long run
> > than any of the others.
> 
> for instance, some part of EVMS design is motivated by IBM's political
> desire to permit its bank customers, who have horrible old OS/2 systems,
> to transparently use OS/2 volumes.  it's not as if IBM couldn't provide
> a simple, user-level migration tool.

Well, you try and convert a few TB of data in a few hour outage window
and pray everything goes well (and then have to convert _back_ to the
old format once you find a bug in the new environment).  You have just
never worked in an environment where the time constraints are tight,
and you CANNOT do the migration offline, or in advance, or whatever.

> it's not as if the Linux community is going to rush out and say
> "let's all start use OS/2 volumes everywhere!"

Well, it's not like most of the Linux community is rushing out and saying
"let's all start using Amiga AFFS filesystems" either, but that didn't
prevent it from being included in the kernel.

I actually DO prefer AIX LVM metadata over the Linux LVM metadata,
and it is NO CONTEST when you are comparing it to the "DOS partitions"
that you seem to prefer so much.

> the best part of Linux is its willingness to throw out old designs;

The best part of Linux is that it accepts a lot of people into the fold,
each of whom has their own special needs, and can change it to meet
those needs.

> a big system like EVMS has its own resistance to such redesign.

???  A big system like the VM/VFS/networking/etc has its own resistance to
such redesign too, but that doesn't mean that they haven't been hacked and
diced and re-assembled like Frankenstein several times.  Everything has
to start somewhere, and if you want until everyone reaches "consensus"
on what is the "best" way to implement it, we would all still be running
MS DOS or Minix.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: [Evms-devel] Re: Linux v2.5.42

[Shawn]

On 10/13, Christoph Hellwig said something like:
> On Sun, Oct 13, 2002 at 11:16:24PM +0800, Michael Clark wrote:
> > On 10/13/02 21:49, Christoph Hellwig wrote:
> > > On Sun, Oct 13, 2002 at 08:41:20PM +0800, Michael Clark wrote:
> _I_ don't want to get EVMS in, sorry.  I _do_ want a proper volume
> managment framework, but I can live with it not beeing in before 2.8.

I think this is where you're going to get the most disagreement.

It was included in mainline, then it just goes away? Linus has no
obligation at all to include anything, but a lot of people depend
on it.

Yeah yeah, distros can include it at will, but mainline inclusion is the
best way to get large exposure and testing to the thing.

Having said all that, given that your premises are true regarding the
code design problems you have with EVMS, you have a valid point about
including it in mainline. The question is, is this good enough to ignore
having a logical device management system?!?

--
Shawn Leas
core@enodev.com

I put my air conditioner in backwards.  It got cold outside.
The weatherman on TV was confused.  "It was supposed to be hot
today."
						-- Stephen Wright

Re: [Evms-devel] Re: Linux v2.5.42

[Shawn]

On 10/13, Alexander Viro said something like:
> 	Mostly those who won't have to clean up the mess afterwards.
> For the record, my vote is "not ready".

Oh shit! This is the "Al Viro stink test" Linus spoke of.

Now, if no LVM type ifrastructure is included in 2.6, all (all who use an
LVM of some type) will all have to

1. update to the latest mainline
2. download the latest dm or evms patch
3. fix all the patch rejects themselves (big problem to overcome when
trying to get people to test with the latest kernel)

I'm NOT saying this is some kind of argument toward inclusion. I guess
I'm just lamenting. I really hoped I'd have one less 3rd party patch to
maintain in my own personal tree.

--
Shawn Leas
core@enodev.com

I was in the first submarine.  Instead of a periscope, they had
a kaleidoscope.  "We're surrounded."
						-- Stephen Wright

Re: Linux v2.5.42

[Christoph Hellwig]

(full quote deleted, please try stop that)

> Good for you. Most people can't/won't wait for it. They will see that linux 
> doesn't have a key feature for enterprises, and say that linux still isn't 
> mature enough for them and at best only use linux on some dinky little 
> webservers, like it has been used in the past.

Please stop trolling.  Linux ised used in many areas, and you can
patch in whathever you want to feel "enteprise ready".  Beeing
that is not a primary focus of the Linux Kernel developmen and won't be.

Re: Linux v2.5.42

[Christoph Hellwig]

On Sun, Oct 13, 2002 at 10:24:11PM +0200, Bernd Eckenfels wrote:
> In article <Pine.LNX.4.33.0210131545510.17395-100000@coffee.psychology.mcmaster.ca> you wrote:
> > for instance, some part of EVMS design is motivated by IBM's political
> > desire to permit its bank customers, who have horrible old OS/2 systems,
> > to transparently use OS/2 volumes.
> 
> Some parts? I guess it is one module. What is wrong with this. Support for
> non standard partition and slice types is currently cluttering up the kernel
> source. I will be more than happy to see this in a EVMS module.

Umm, you consider moving coee from fs/partitions/*.c to drivers/evms/*.c
a cleanup?

Re: [Evms-devel] Re: Linux v2.5.42

[Christoph Hellwig]

On Mon, Oct 14, 2002 at 12:18:52AM +0800, Michael Clark wrote:
> one you decides. At the end of the day it is just another 'driver'
> and I don't think it's fair to place a higher benchmark of quality
> on EVMS than all the other drivers in the kernel

If you followed lkml you'll see that I even explain authors of
very small drivers how to fit the kernel standards.  The situation
with those is a little different as they are not a framework and
don't add new APIs.  Thus it's only a correctness and style issues.

EVMS on the other hand is not only a lot of code but also a framework,
i.e. it folows certain design principles.  And I fundamentally
disagree with some of those.

> Some of us have large arrays and SANs where the absence a volume
> manager is a big thing.

Not having EVMS ~= not having a volume manager.  I don't want
to have to manage my storage farms without a volume manager either,
but that doesn't have to mean that I like the EVMS design.

Re: [Evms-devel] Re: Linux v2.5.42

[Christoph Hellwig]

On Mon, Oct 14, 2002 at 01:41:51AM +0800, Michael Clark wrote:
>  From the discussion so far:
> 
> Pros
> * Simplify ioctl routing to plugins

* allow code reuse
* simplify userspace access to intermediate layer
* avoid data duplication
* avoid having different data structures for very differen things

> Cons
> * Chew up a minor
> * Get a block device we don't need or want (ie. we can still easily
>    directly access the underlying physical block devices)
> * loose purely logical remapping abstraction in plugins

Explain the exact meaning of this to non/native speakers like me, please

> * Complicate mapping of request queues to devices (ie. shouldn't only
>    the top level volume device and the underlying physical devices need
>    request queues)

You need struct request queue as data structure, but you don't actually
need a queue.  Please check the code.

And no, I don't think having a peoper, custom make_request_fn will
complicate the code.

Re: [Evms-devel] Re: Linux v2.5.42

[Christoph Hellwig]

On Sun, Oct 13, 2002 at 10:23:23PM -0600, Andreas Dilger wrote:
> Maybe there are some warts in EVMS, but that doesn't mean we don't
> need it (or equivalent) in Linux.

Full agreement here.  But until we have something that is in
a mergable shape I don't want to see it in mainline.

Re: [Evms-devel] Re: Linux v2.5.42

[Rik van Riel]

On Mon, 14 Oct 2002, Shawn wrote:

> Having said all that, given that your premises are true regarding the
> code design problems you have with EVMS, you have a valid point about
> including it in mainline. The question is, is this good enough to ignore
> having a logical device management system?!?

You're acting like EVMS was the only logical volume manager out there.

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: [Evms-devel] Re: Linux v2.5.42

[Christoph Hellwig]

On Sun, Oct 13, 2002 at 10:43:55PM -0600, Andreas Dilger wrote:
> I never did get a clear understanding why Christoph wants access to
> "intermediate" block devices from EVMS, except for the ioctl issue.

It's not really the userspace access that matters (it comes for free
when doing it properly) but more that I want to avoid duplicating
kernel-internal data structures and code.  Just look at ldev_mgr.c
in the evms source code and see how much simpler it would get if we
merged struct evms_logical_node (and it's members) into struct gendisk and
struct block_device - sure that's not a trivial task, but it'll pay
out in the long term.

> It's like "ls -l" showing you each and every block that makes up a file,
> or "ps aux"

It's more like ps aux showing you all threads of a multithreaded
process.  Yes, people have turned it off now, but you really want
to be able to see it without doing hacks.

Re: [Evms-devel] Re: Linux v2.5.42

[Christoph Hellwig]

On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> Having said all that, given that your premises are true regarding the
> code design problems you have with EVMS, you have a valid point about
> including it in mainline. The question is, is this good enough to ignore
> having a logical device management system?!?

It is not good enough to ignore it.  It is good enough to postpone
integration for 2.7.

Now that Al has sorted out lots of the block device mess in 2.5
I will work together with whoever is interested in it (i.e. the EVMS
folks) to integrate proper higher-level volume-management into
the kernel once the next unstable series opens.

Coing up with lots of code just before feature freeze is just not the way
infrastructure work is done Linux.

Re: [Evms-devel] Re: Linux v2.5.42

[Jeff Garzik]

Christoph Hellwig wrote:
> Coing up with lots of code just before feature freeze is just not the way
> infrastructure work is done Linux.

s/is/should be/

I agree with you 100% but being brutally frank this _is_ how things 
often get done...  [and we should continue to work to change this]

	Jeff

Re: [Evms-devel] Re: Linux v2.5.42

[Shawn]

I hadn't heard comments yet that anyone thought of dm as ready yet.

This may be the case by now.

On 10/14, Rik van Riel said something like:
> On Mon, 14 Oct 2002, Shawn wrote:
> 
> > Having said all that, given that your premises are true regarding the
> > code design problems you have with EVMS, you have a valid point about
> > including it in mainline. The question is, is this good enough to ignore
> > having a logical device management system?!?
> 
> You're acting like EVMS was the only logical volume manager out there.

--
Shawn Leas
core@enodev.com

My grandfather invented Cliff's Notes. It all started back in 1912...
well, to make a long story short...
						-- Stephen Wright

Re: [Evms-devel] Re: Linux v2.5.42

[Shawn]

On 10/14, Christoph Hellwig said something like:
> On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> > Having said all that, given that your premises are true regarding the
> > code design problems you have with EVMS, you have a valid point about
> > including it in mainline. The question is, is this good enough to ignore
> > having a logical device management system?!?
> 
> It is not good enough to ignore it.  It is good enough to postpone
> integration for 2.7.

I just wish logical volume management in general had not been so
abandoned in mainline in the first place. I'm not saying Linus unfairly
excluded patches, and I'm not saying patches weren't available. I'm just
saying the dynamics of Linus and the maintainers did not allow for a
healthy LVM in mainline, resulting in decay.

If LVM1's destiny was to die during 2.5, then I wish there would have
been a replacement ready during 2.5's lifecycle. Otherwise, keep
creaking along with what's there, and fix it.

The larger question of volume management should have been addressed
before this whole mess happened. It really was, but LVM1 maintenance was
somewhat abandoned in favor of device mapper, and now it's broken, and
the holy wars are upon us again because many are in fear of losing
functionality important to them (at least the ubiquitous nature of the
functonality), and there is panic.

> Now that Al has sorted out lots of the block device mess in 2.5
> I will work together with whoever is interested in it (i.e. the EVMS
> folks) to integrate proper higher-level volume-management into
> the kernel once the next unstable series opens.

I look forward to it. In spite of my personal goals on this, I do
appreciate your pickiness.

> Coing up with lots of code just before feature freeze is just not the way
> infrastructure work is done Linux.

I just wish there were less veto-esque ways to handle EVMS in *-stable.

--
Shawn Leas
core@enodev.com

I put my air conditioner in backwards.  It got cold outside.
The weatherman on TV was confused.  "It was supposed to be hot
today."
						-- Stephen Wright

Re: [Evms-devel] Re: Linux v2.5.42

[Oliver Neukum]

Am Montag, 14. Oktober 2002 18:21 schrieb Christoph Hellwig:
> On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> > Having said all that, given that your premises are true regarding the
> > code design problems you have with EVMS, you have a valid point about
> > including it in mainline. The question is, is this good enough to ignore
> > having a logical device management system?!?
>
> It is not good enough to ignore it.  It is good enough to postpone
> integration for 2.7.

No, that is not an option. Either evms or lvm2 it must be.
Switching later might be difficult. So it has to be decided
quite soon.

	Regards
		Oliver

Re: [Evms-devel] Re: Linux v2.5.42

[Shawn]

On 10/14, Oliver Neukum said something like:
> Am Montag, 14. Oktober 2002 18:21 schrieb Christoph Hellwig:
> > On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> > > Having said all that, given that your premises are true regarding the
> > > code design problems you have with EVMS, you have a valid point about
> > > including it in mainline. The question is, is this good enough to ignore
> > > having a logical device management system?!?
> >
> > It is not good enough to ignore it.  It is good enough to postpone
> > integration for 2.7.
> 
> No, that is not an option. Either evms or lvm2 it must be.
> Switching later might be difficult. So it has to be decided
> quite soon.

I know this has the potential of being an unfortunate situation for
many, but edicts do not help.

If neither LVM2 or EVMS are truly ready, no one is beholden to anyone
else as to anything's inclusion in mainline.

It's a matter of marketing so say whether Linux has volume management.
If all the distros have LVM in some form, then "Linux has an LVM". So,
no one can really say "Linux doesn't have an LVM so it's not enterprise
ready.

It's just really inconvenient for those who
 1. want to run a devel kernel
 2. want to run an LVM
 3. want to be really really up-to-date
because we (the testers) have to do a lot of the forward porting grunt
work fixing all the patch rejects and compile errors that inevitably
come.

--
Shawn Leas
core@enodev.com

I have a hobby...I have the world's largest collection of sea shells.
I keep it scattered on beaches all over the world.  Maybe you've seen
some of it... 
						-- Stephen Wright

Re: Linux v2.5.42

[Bernd Eckenfels]

In article <20021014161112.A17683@infradead.org> you wrote:
> Umm, you consider moving coee from fs/partitions/*.c to drivers/evms/*.c
> a cleanup?

Actually no, but I consider a registration interface for partition handlers
a cleanup, but I must admit I am not up to date to 2.5.

Personally I would love to see the device mapper stuff as the foundation for
evms. Hopefully those teams may meet in the middle :)

I am afraid partition handling is most of the time needed for root file
systems, so this will put more need for initrd solutions into the picture.

Greetings
Bernd

Re: [Evms-devel] Re: Linux v2.5.42

[Oliver Neukum]

> If neither LVM2 or EVMS are truly ready, no one is beholden to anyone
> else as to anything's inclusion in mainline.
>
> It's a matter of marketing so say whether Linux has volume management.
> If all the distros have LVM in some form, then "Linux has an LVM". So,
> no one can really say "Linux doesn't have an LVM so it's not enterprise
> ready.

This is not true. Something has to be in the mainline, so that bugs can
be fixed. This too important to be left to distributors.

Besides people who compile their own kernels are not that unimportant.

	Regards
		Oliver

Re: [Evms-devel] Re: Linux v2.5.42

[Shawn]

On 10/14, Oliver Neukum said something like:
> 
> > If neither LVM2 or EVMS are truly ready, no one is beholden to anyone
> > else as to anything's inclusion in mainline.
> >
> > It's a matter of marketing so say whether Linux has volume management.
> > If all the distros have LVM in some form, then "Linux has an LVM". So,
> > no one can really say "Linux doesn't have an LVM so it's not enterprise
> > ready.
> 
> This is not true. Something has to be in the mainline, so that bugs can
> be fixed. This too important to be left to distributors.

As I said before, edicts help no one. I appreciate your sentiment, and
to some degree share it, but you have to take a non-cheerleader look at
things like this.

> Besides people who compile their own kernels are not that unimportant.

No one is saying that. No one is even saying that mainline inclusion
isn't extremely beneficial to EVMS or DM. The question isn't whether DM
or EVMS would be impacted more positively if it were included. The
question is whether mainline would be better off including them, and not
the other way around.

Also, let me define the phrase "better off" to mean "better off W.R.T.
design, architecture, overall code quality, abstractions in the right
place, etc etc", and not to mean politically, as in, more users.

Honestly though, if you aren't able to do the work it takes to be a 3rd
party patch tester, it's less likely you can properly test or submit
proper bug reports in the first place.

--
Shawn Leas
core@enodev.com

I had some eyeglasses.  I was walking down the street when
suddenly the prescription ran out.
						-- Stephen Wright

Re: [Evms-devel] Re: Linux v2.5.42

[Alexander Viro]

On Tue, 15 Oct 2002, Oliver Neukum wrote:

> 
> > If neither LVM2 or EVMS are truly ready, no one is beholden to anyone
> > else as to anything's inclusion in mainline.
> >
> > It's a matter of marketing so say whether Linux has volume management.
> > If all the distros have LVM in some form, then "Linux has an LVM". So,
> > no one can really say "Linux doesn't have an LVM so it's not enterprise
> > ready.
> 
> This is not true. Something has to be in the mainline, so that bugs can
> be fixed. This too important to be left to distributors.
> 
> Besides people who compile their own kernels are not that unimportant.

As for the bugs getting fixed, one of the main problems with EVMS merge
now is that it (as any merge) shifts part of that very burden from EVMS
maintainers to other developers *and* *it* *shifts* *too* *much*.

That's what "ready to be merged" boils down to.  It's a question of how
many problems will be inflicted by the merge upon current and future
development - over all kernel.  AFAICS in its current state EVMS is not
ready.  And yes, it means that EVMS maintainers get to play catch up for
a while.  Nobody refuses to help them, BTW.

Re: [Evms-devel] Re: Linux v2.5.42

[Oliver Neukum]

> As I said before, edicts help no one. I appreciate your sentiment, and
> to some degree share it, but you have to take a non-cheerleader look at
> things like this.

I'd be happy if there were no such problem.

> > Besides people who compile their own kernels are not that unimportant.
>
> No one is saying that. No one is even saying that mainline inclusion
> isn't extremely beneficial to EVMS or DM. The question isn't whether DM
> or EVMS would be impacted more positively if it were included. The
> question is whether mainline would be better off including them, and not
> the other way around.
>
> Also, let me define the phrase "better off" to mean "better off W.R.T.
> design, architecture, overall code quality, abstractions in the right
> place, etc etc", and not to mean politically, as in, more users.

While these are important choices, Linux is an OS for practical use
and needs to meet some minimum of necessary features.

> Honestly though, if you aren't able to do the work it takes to be a 3rd
> party patch tester, it's less likely you can properly test or submit
> proper bug reports in the first place.

That's not the problem. There'd be bug reports from half a dozen vendor
kernels, one incorporating lvm2, the other evms and probably several
versions of them plus their own kernel patches.
A gigantic mess.

	Regards
		Oliver

Re: [Evms-devel] Re: Linux v2.5.42

[Alexander Viro]

On Tue, 15 Oct 2002, Oliver Neukum wrote:

> > Also, let me define the phrase "better off" to mean "better off W.R.T.
> > design, architecture, overall code quality, abstractions in the right
> > place, etc etc", and not to mean politically, as in, more users.
> 
> While these are important choices, Linux is an OS for practical use
> and needs to meet some minimum of necessary features.

Come back when you are in position to make demands.  Until then, feel
free to bugger off.

Arrogant demands are _not_ going to impress anybody - $DEITY witness,
arrogance is not in short supply around here and with waay better
credentials to back it up.

If you are willing to help EVMS folks - go ahead and offer them your help in
cleaning the codebase up.  _That_ can change situation.  Public wankathlon
will earn you a warm spot in killfiles and fail to affect any merges in
any direction.

*plonk*

Re: [Evms-devel] Re: Linux v2.5.42

[Oliver Neukum]

Am Dienstag, 15. Oktober 2002 01:16 schrieb Alexander Viro:
> On Tue, 15 Oct 2002, Oliver Neukum wrote:
> > > Also, let me define the phrase "better off" to mean "better off W.R.T.
> > > design, architecture, overall code quality, abstractions in the right
> > > place, etc etc", and not to mean politically, as in, more users.
> >
> > While these are important choices, Linux is an OS for practical use
> > and needs to meet some minimum of necessary features.
>
> Come back when you are in position to make demands.  Until then, feel
> free to bugger off.

Demands? That was an oppinion, not a demand. And a little civility would
suit you just fine.

> Arrogant demands are _not_ going to impress anybody - $DEITY witness,
> arrogance is not in short supply around here and with waay better
> credentials to back it up.
>
> If you are willing to help EVMS folks - go ahead and offer them your help
> in cleaning the codebase up.  _That_ can change situation.  Public
> wankathlon will earn you a warm spot in killfiles and fail to affect any
> merges in any direction.

I did improvements to it to the best of my abilities, which as I freely admit
lesser than yours.
If a short civilised discussion earns me a place in your killfiles I'll happily
reside there.

	Oliver

Re: [Evms-devel] Re: Linux v2.5.42

[Andrew Clausen]

On Mon, Oct 14, 2002 at 07:16:22PM -0400, Alexander Viro wrote:
> If you are willing to help EVMS folks - go ahead and offer them your help in
> cleaning the codebase up.

They refused my patches.

Does anyone want me to dig them up?

Andrew

Re: [Evms-devel] Re: Linux v2.5.42

[Heinz J . Mauelshagen]

On Mon, Oct 14, 2002 at 04:47:30PM -0500, Shawn wrote:
> On 10/14, Christoph Hellwig said something like:
> > On Mon, Oct 14, 2002 at 09:20:48AM -0500, Shawn wrote:
> > > Having said all that, given that your premises are true regarding the
> > > code design problems you have with EVMS, you have a valid point about
> > > including it in mainline. The question is, is this good enough to ignore
> > > having a logical device management system?!?
> > 
> > It is not good enough to ignore it.  It is good enough to postpone
> > integration for 2.7.
> 
> I just wish logical volume management in general had not been so
> abandoned in mainline in the first place. I'm not saying Linus unfairly
> excluded patches, and I'm not saying patches weren't available. I'm just
> saying the dynamics of Linus and the maintainers did not allow for a
> healthy LVM in mainline, resulting in decay.
> 
> If LVM1's destiny was to die during 2.5, then I wish there would have
> been a replacement ready during 2.5's lifecycle. Otherwise, keep
> creaking along with what's there, and fix it.

True, we aim to replace the LVM1 driver with device-mapper in 2.5, which we
strongly believe to be a first step to generic volume management in the kernel.

Feel free to blame us that we didn't have more capacity to
make it happen earlier ;-)

device-mapper is in the -ac kernel since last week. Thanks Alan.

Please have a look at the rather small amount of clean code.

> 
> The larger question of volume management should have been addressed
> before this whole mess happened. It really was, but LVM1 maintenance was
> somewhat abandoned in favor of device mapper, and now it's broken, and
> the holy wars are upon us again because many are in fear of losing
> functionality important to them (at least the ubiquitous nature of the
> functonality), and there is panic.

There's no need to be afraid because device-mapper and the LVM2 tools offer
a compatible path _now_ supporting all given LVM1 configurations.

The device-mapper code has already been merged by Alan (which is a very good
approval IMNSHO) and is rather easy to overlook.

Please help us and have a look...

> 
> > Now that Al has sorted out lots of the block device mess in 2.5
> > I will work together with whoever is interested in it (i.e. the EVMS
> > folks) to integrate proper higher-level volume-management into
> > the kernel once the next unstable series opens.
> 
> I look forward to it. In spite of my personal goals on this, I do
> appreciate your pickiness.
> 
> > Coing up with lots of code just before feature freeze is just not the way
> > infrastructure work is done Linux.
> 
> I just wish there were less veto-esque ways to handle EVMS in *-stable.
> 
> --
> Shawn Leas
> core@enodev.com
> 
> I put my air conditioner in backwards.  It got cold outside.
> The weatherman on TV was confused.  "It was supposed to be hot
> today."
> 						-- Stephen Wright
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Evms-devel mailing list
> Evms-devel@lists.sourceforge.net
> To subscribe/unsubscribe, please visit:
> https://lists.sourceforge.net/lists/listinfo/evms-devel

-- 

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

[Alexander Kellett]

On Sun, Oct 13, 2002 at 05:57:06PM -0200, Rik van Riel wrote:
> All you need is:
> 1) a kernel level driver that can map devices, ie. a device mapper
> 2) user space tools that can parse the volume metadata and tell the
>    kernel how to map each chunk at initialisation or mount time

stupid user question here. does the dm stuff make
vmware partition mounts easy without needing
all the nbd overhead?, or would the mappings be
so large that they negate the decrease in nbd
overhead?

Alex

Re: [Evms-devel] Re: Linux v2.5.42

[Andrew Clausen]

On Tue, Oct 15, 2002 at 09:51:15AM -0500, Steve Pratt wrote:
> Please don't say that. I just searched the EVMS mailing list archives
> dating back to December 2000 and there is not a single patch from you
> Andrew. One or 2 pieces of psuedo-code, but no real patches.  Feel free to
> look yourself, the archives are online.

Ah, you are correct.  I was trying to find out if there was interest
in me actually making the patches, before spending the time on it.

I came to the conclusion there was no interest.

> > Does anyone want me to dig them up?
> 
> Sure, if they really exist.
> 
> Andrew, just so you are aware, a number of your suggestions did make it
> into EVMS even if you are not aware of it because they did not hapopen
> immediately.  Some that come to mind that I think you originally proposed
> are plug-in progress indicators (from pedtimer), nesting of partitions,
> plug-in record header changes (multiple plug-ins per file).  These are just
> the ones that come to mind, so keep the suggestion (and patches if you can
> find any) coming.

Ah, I didn't realise :)  Will do, if I can find some free time.
(Uni is *really* heavy ATM :( )

Cheers,
Andrew

Re: [Evms-devel] Re: Linux v2.5.42

[Steve Pratt]

Andrew Clausen wrote:

>On Mon, Oct 14, 2002 at 07:16:22PM -0400, Alexander Viro wrote:
>> If you are willing to help EVMS folks - go ahead and offer them your
help in
>> cleaning the codebase up.

>They refused my patches.

Please don't say that. I just searched the EVMS mailing list archives
dating back to December 2000 and there is not a single patch from you
Andrew. One or 2 pieces of psuedo-code, but no real patches.  Feel free to
look yourself, the archives are online.

> Does anyone want me to dig them up?

Sure, if they really exist.

Andrew, just so you are aware, a number of your suggestions did make it
into EVMS even if you are not aware of it because they did not hapopen
immediately.  Some that come to mind that I think you originally proposed
are plug-in progress indicators (from pedtimer), nesting of partitions,
plug-in record header changes (multiple plug-ins per file).  These are just
the ones that come to mind, so keep the suggestion (and patches if you can
find any) coming.

Steve

Re: [Evms-devel] Re: Linux v2.5.42

[Mark Peloquin]

On 10/14/2002 at 05:57 PM, Alexander Viro wrote:

> As for the bugs getting fixed, one of the main problems with EVMS merge
> now is that it (as any merge) shifts part of that very burden from EVMS
> maintainers to other developers *and* *it* *shifts* *too* *much*.

> That's what "ready to be merged" boils down to.  It's a question of how
> many problems will be inflicted by the merge upon current and future
> development - over all kernel.  AFAICS in its current state EVMS is not
> ready.  And yes, it means that EVMS maintainers get to play catch up for
> a while.

We don't want to shift the burden of EVMS onto
other developers. We are willing to play catch up
for a while, however the feature-freeze date is
looming.

> Nobody refuses to help them, BTW.

Can you identify areas you feel need special
attention?

Mark