Daniel Seuffert
Well-Known Member
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