[lkml]   [2009]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Tux3] Current Activities?
    On Thursday 06 August 2009, Ingo Molnar wrote:
    > * Daniel Phillips <> wrote:
    > > [...] I will say this now: if we are invited to merge in the next
    > > major release, or in -mm or whatever, we will happily do it. If we
    > > are not invited to merge, nobody has any cause to complain about
    > > progress slowing down. [...]
    > The thing is, if you are waiting for an 'invite to upstream Linux
    > merge' that could be a _very_ long wait: i've yet to see a single
    > one ever since i started hacking Linux ~14 years ago ;-)

    Hi Ingo,

    We were already sorta-kinda invited to merge, as I read it, having received advice to merge early while the code base remains small
    instead of adding more features and risking premature bloat. I seem to
    recall there was a dissenter at that time on the basis of lack of
    atomic commit, and we chose to follow the latter advice instead of the
    former, arguably a mistake.

    > The model that Linux has been following for the past 10+ years is
    > for new kernel projects to request inclusion. I.e. you push your
    > patches upstream: you send patches and a pull request to the
    > appropriate people/lists such as lkml.
    > This is done so because merging patches is a fundamentally
    > hierarchical process, and the people merging _your_ patches are the
    > real maintenance bottleneck, not you.
    > So it is not Linus and other maintainers who are searching the web
    > for projects to merge and sending out 'invites' but the other way
    > around: projects try to get upstream by submitting patches (which
    > get reviewed and accepted or rejected).

    With 20-20 hindsight, we should have gone for a merge immediately after
    the SCALE 7X demo, at which time Tux3 was reliably but without
    atomic commit. Instead, we decided to heed those asking for atomic
    commit before merge. This turned out to be a bad idea, because my
    available time soon became severely constrained. Work on atomic commit
    has progressed over the last few months, but slowly. If we had merged
    back in February this work would have progressed faster and been done
    by now. As it is, we will probably forge on with the atomic commit work
    rather than changing course and looking for a merge right away, because
    there has been considerable progress in that direction. Also, my time
    is not quite as constrained as it was - still constrained, but not quite
    as severely as recently.

    Meanwhile Hirofumi has dauntlessly forged on, extracting design details
    from me, adding some of his own, generally subjecting everything to
    minute scrutiny, and in the process turning out a significant volume of
    high quality code. If I had to state what the best thing that could
    happen to Tux3 is, it would be: somebody steps up to sponsor Hirofumi.
    He has done all that work strictly as a volunteer without support of any
    kind, and he could use some. Not to mention the fact that as FAT
    maintainer we would be well served to have Hirofumi in a comfort zone,
    given recent developments on that front.

    > So if you'd like your code to be merged upstream you better start
    > this process now - this alone can take a lot of time: months (or
    > years in certain cases). But it is still a much shorter time-span
    > than an 'invite to merge' ;-)
    > Ingo

    My "invite to merge" comment was made in the context of various comments
    about insufficiently rapid progress, and should not be taken out of
    context. We are well aware of the traditional merging procedure. We
    certainly are not waiting for any maintainer action, but rather for more
    progress from ourselves. There are various possibilities to speed that
    up. See "sponsor Hirofumi" above. I myself do not need sponsorship at
    this point, what I need is more time on my hands, and only I can do
    anything about that. (As of today, I do have a little more time
    available, hence this post.)

    In fact, our merge process has been in progress since February. As we
    see it, it goes like this:

    1) Implement and verify atomic commit correctness at least for a
    large subset of filesystem operations.

    2) Clean the kernel part of the code base to a respectable state.

    3) Commence our post-address-repost cycle with intent to merge.

    We are at step 1 and I can't say how long it will take to get to step 2.
    It is on the way. Any help we get will hurry it along.

    I will very briefly address Ted's question, which amounts to: "why
    do we want Tux3?" I think Tux3 fills an empty niche in our filesystem
    ecology where a simple, clean and modern general purpose filesystem
    should exist and there is none. In concrete terms, Tux3 implements a
    single-pointer-per-extent model that Btrfs and ZFS do not. This allows
    a very simple *physical* design, with much complexity pushed to the
    *logical* level where things generally behave better. A simple physical
    design offers many benefits, including making it easier to take a run at
    that holiest of holy grails, online check and repair.

    In even more concrete terms, Tux3 already demonstrates a tiny memory
    footprint, unlike Btrfs or ZFS. Its CPU footprint is also tiny. As
    such, Tux3 could easily run on a cellphone or smaller device, while
    offering a full range of "big filesystem" capabilities. (Note that
    Zumastor already proves we know how to do replication properly:



     \ /
      Last update: 2009-08-09 01:49    [W:0.036 / U:32.252 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site