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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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