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

[Christoph Hellwig <hch@infradead.org>]

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