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