"altes" vinum liegt im Sterben

[Daniel Seuffert]

Speziell für unsere Vinum-Freunde (Axel ) diese neueste Meldung von Poul-Henning Kamp (phk), der das baldige "Sterben" des bisherigen vinum ankündigt, vinum wird durch geom_vinum ersetzt, natürlich nicht mehr in 5.3:

Date: Tue, 07 Sep 2004 13:37:01 +0200
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Subject: HEADSUP: phk_bufwork IFP4 later this month.
To: current@freebsd.org
Message-ID: <16125.1094557021@critter.freebsd.dk>


Throughout the second half of this month I will integrate the
phk_bufwork branch into HEAD/6-CURRENT in a sequence of commits.

There are a couple of BURN_BRIDGES sideeffects of this:

(old)vinum gets removed.
The usage of struct buf in oldvinum would need to be seriously
reworked to work with the new struct bufobj and this is far more
work than makes sense. Geom_vinum will have to fill the void.

Device nodes on non-DEVFS filesystems gets desupport.
This is a step in the direction of getting vnode locking
simplified.

Temporary suspension of the FFS specific VOP_GETPAGES().
FFS will use the generic getpages implementation like
all other filesystems for now. It will come back further
down the road when the map/umap and scatter/gather semantics
of struct bio gets ironed out.

On the plus side the highlights are:

Introduction of struct bufobj as the buffercache handle.
All vnodes contain a bufobj, so a lot is just like it used
to be, but a general movement from using vnodes to bufobj
in a lot of places in the buffercache is the result.
Eventually, this will make it possible for geom classes to
use the buffer cache for caching metadata.

Local filesystems use geom consumer instead of vnode.
This takes some of the recursion and lock pressure off the
vnode layer. Sideeffects are the ability to have multiple
read-only mounts of the same filesystem and correct r/w
access semantics during remount up/downgrades.

You can help test this code already now by running the phk_bufwork
branch from perforce.

Poul-Henning

 

[asg]

Man kann ja froh sein das FreeBSD noch "FreeBSD" heisst, und noch nicht "phkBSD" (zumindest hat man Unkenrufe in diese Richtung schon vernommen....)

 

[josef]

Man kann ja froh sein das FreeBSD noch "FreeBSD" heisst, und noch nicht "phkBSD" (zumindest hat man Unkenrufe in diese Richtung schon vernommen....)

und worauf basiert diese unqualifizierte aussage?

 

[carbuncle]

Mhh, dass vinum fliegt, ist jetzt nicht so prickelnd. Ich hatte mir fest vorgenommen, wenn Releng_5 STABLE wird, vinum mit 2 Platten gespiegelt aufzusetzen.

Was habe ich jetzt für alternativen, wenn der 5er STABLE wird (glaub so im okt. wenn der Zeitplan klappt)????

carb

 

[MrFixit]

und worauf basiert diese unqualifizierte aussage?

Gerade als Committer (du bist doch der Josef, oder?) sollte man die Sache mit dem phkBSD eigentlich kennen.

PS: Daenische Aexte sind verdammt scharf

 

[asg]

und worauf basiert diese unqualifizierte aussage?

Auf nichts? Evtl. hätte ich einfach nur ein ;-) mit einpflegen sollen...
Ansonsten, bei der zeit die phk hat, durch die Spenden ist es ihm ja möglich voll für das FreeBSD Project zu arbeiten, kommt natürlich auch das meiste vom ihm. Entsprechende Kommentar gab es auch irgendwo unter d.c.o.u.b.

 

[marzl]

arg manno und was heisst das jetzt?
geom_vinum ist dann quasi der gleichwertige ersatz?
wird ein vinum plex einfach übernommen oder muss es dann neue angelgt werden?
fragen über fragen

 

[asg]

@marzl
Wie der Umstieg bei einem funktionierenden vinum RAID auf ein gvinum funktionieren soll, frage ich mich auch. Evtl. ganz einfach, evtl. gar nicht...

 

[marzl]

super aussichten. bin gespannt.

 

[MrFixit]

-CURRENT lesen. Du musst nur vinum_load durch gvinum_load ersetzen und im rc-script den gvinum Aufruf anpassen. Fertig ist die Laube (das mit dem rc-Skript sollte aber mal jmd. committen...)
http://freebsd.rambler.ru/bsdmail/freebsd-current_2004/msg16101.html

Achja, /etc/fstab muss noch angepasst werden. Aber das Datenlayout an sich hat sich nicht geandert.

 

[marzl]

na das klingt ja doch etwas "vertrauenswürdiger"

 

[josef]

Gerade als Committer (du bist doch der Josef, oder?) sollte man die Sache mit dem phkBSD eigentlich kennen.

PS: Daenische Aexte sind verdammt scharf

ja aber ich finde es unnoetig rumzuhussen. da bin ich einfach allergisch drauf. tut mir leid.

 

[josef]

Auf nichts? Evtl. hätte ich einfach nur ein ;-) mit einpflegen sollen...
Ansonsten, bei der zeit die phk hat, durch die Spenden ist es ihm ja möglich voll für das FreeBSD Project zu arbeiten, kommt natürlich auch das meiste vom ihm. Entsprechende Kommentar gab es auch irgendwo unter d.c.o.u.b.

rwatson hat eigentlich den hoechsten commitscount.

 

[asg]

@josef
Vergessen wir das. Es war ironisch gemeint, also was solls.