lkml.org 
[lkml]   [2002]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Evms-devel] Re: Linux v2.5.42
    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

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

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:0.026 / U:29.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site