Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 01/12/04

  • Next message: Josef Karthauser: "Problems with syslogd under 5.2-RELEASE" 
    To: "Greg 'groggy' Lehey" <grog@FreeBSD.org>
Date: Mon, 12 Jan 2004 10:13:27 +0100

    In message <20040111051649.GK7617@wantadilla.lemis.com>, "Greg 'groggy' Lehey"

    >> As much as I would hate to see RF and Vinum disappar from our
    >> source tree, maybe what we need to do is to kick them both into
    >> "training-camp" in p4 while you and Greg look the other way.
    >
    >Hmm. I can't see why they have to disappear from the source tree, [...]

    I forgot to mention on rather important factor in this equation:

    If nothing happens, vinum is going to break even more very soon.

    The plan for the cleanup of the buffer cache, such as we drew it
    up at BSDcon, says that filesystems will go directly to GEOM for
    disk service rather than detour through the vnode layer, SPECFS and
    then to GEOM. (This is not a matter of our choice of bike-shed
    color, this is a matter of SMP performance, locking sanity and
    buf/VM performance.)

    The first step of this has actually happened with the swap_pager
    which now goes directly to GEOM, and that is why you cannot put
    your swapspace on a vinum volume any more.

    The next target is UFS.

    The softupdates and snapshot support, because of the way the buffer
    cache interacts with SPECFS, has callback hooks in SPECFS which do
    not belong there.

    The next step is to move UFS to go directly to GEOM and at the same
    time pull the callbacks out of SPECFS and into UFS (FFS really)
    where they belong.

    Once I proceed with that step, you cannot mount UFS on a vinum
    volume.

    After that, the rest of the filesystems will follow, one by one.

    The question in my mind is: What if vinum is not fixed by then ?

    If it is decided to leave vinum in the CVS tree at this point in
    time, do we all agree and accept that if not fixed by then, vinum
    gets disconnected from the build when we proceed with the buffer
    cache cleanup ?

    To give an idea about the relative urgency, we are probably talking
    february or march this year.

    Poul-Henning 

    -- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Josef Karthauser: "Problems with syslogd under 5.2-RELEASE"

    Relevant Pages

    • Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
      ... vinum is going to break even more very soon. ... then to GEOM. ... The next target is UFS. ... cache interacts with SPECFS, has callback hooks in SPECFS which do ...
      (freebsd-hackers)
    • vinum drives crash in 5.2.1 but work in 4.9
      ... when I typed "vinum start" at the root prompt in 5.2.1 I got the ... ata2: at 0xe8020000 on atapci1 ... GEOM: create disk ad0 dp=0xc6a2d560 ...
      (freebsd-questions)
    • Re: Vinum and GEOM: the future
      ... infrastructure component) on one side and the GEOM classes on the other. ... >they specifically asked for a paper about Vinum. ... If you put all of Vinum into one GEOM class, like I did with CCD, ... very general MIRROR class, one very general RAID5 classe etc. ...
      (freebsd-arch)
    • Vinum and GEOM: the future
      ... Vinum and GEOM overlap significantly in their features, ... - Online configuration via the vinum utility program. ...
      (freebsd-arch)
    • RE: HEADS UP [Re: thread+preemption stability improvement]
      ... > ATA driver that is being exposed by PREEMPTION, ... seen with GBDE, GEOM stripe, GEOM vinum and "old" vinum, but I probably ... system was live, and processes were accessing the ataraid arrays, the ...
      (freebsd-current)