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

[Michael Clark <michael@metaparadigm.com>]

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