[lkml]   [2002]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] mount flag "direct"
    On 2002-09-08T11:23:39,
    "Peter T. Breuer" <> said:

    > > do it if you don't know what the node had been working on prior to its
    > > failure.
    > Yes we do. Its place in the topology of the network dictates what it was
    > working on, and anyway that's just a standard parallelism "barrier"
    > problem.

    I meant wrt what is had been working on in the filesystem. You'll need to do a
    full fsck locally if it isn't journaled. Oh well.

    Maybe it would help if you outlined your architecture as you see it right now.

    > > Well, you are taking quite a risk trying to run a
    > > not-aimed-at-distributed-environments fs and trying to make it distributed
    > > by force. I _believe_ that you are missing where the real trouble lurks.
    > There is no risk, because, as you say, we can always use nfs or another off
    > the shelf solution.

    Oh, so the discussion is a purely academic mind experiment; it would have been
    helpful if you told us in the beginning.

    > But 10% better is 10% more experiment for each timeslot
    > for each group of investigators.

    > > What does this supposed "flexibility" buy you? Is there any real value in
    > > it
    > Ask the people ho might scream for 10% more experiment in their 2 weeks.

    > > > You mean "what's wrong with X"? Well, it won't be mainstream, for a start,
    > > > and that's surely enough.
    > > I have pulled these two sentences out because I don't get them. What "X" are
    > > you referring to?
    > Any X that is not a standard FS. Yes, I agree, not exact.

    So, your extensions are going to be "more" mainstream than OpenGFS / OCFS etc?
    What the hell have you been smoking?

    It has become apparent in the discussion that you are optimizing for a very
    rare special case. OpenGFS, Lustre etc at least try to remain useable for
    generic filesystem operation.

    That it won't be mainstream is wrong about _your_ approach, not about those
    "off the shelves" solutions.

    And your special "optimisations" (like, no caching, no journaling...) are
    supposed to be 10% _faster_ overall than these which are - to a certain extent
    - from the ground up optimised for this case?

    One of us isn't listening while clue is knocking.

    Now it might be me, but then I apologize for having wasted your time and will
    stand corrected as soon as you have produced working code.

    Until then, have fun. I feel like I am wasting both your and my time, and this
    isn't strictly necessary.

    Lars Marowsky-Brée <>

    Immortality is an adequate definition of high availability for me.
    --- Gregory F. Pfister

    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:28    [W:0.025 / U:9.276 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site