From owner-freebsd-current@FreeBSD.ORG Tue Sep 7 11:37:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37FAF16A4CE for ; Tue, 7 Sep 2004 11:37:04 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AAB643D31 for ; Tue, 7 Sep 2004 11:37:03 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i87Bb18I016126 for ; Tue, 7 Sep 2004 13:37:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Tue, 07 Sep 2004 13:37:01 +0200 Message-ID: <16125.1094557021@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: HEADSUP: phk_bufwork IFP4 later this month. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 11:37:04 -0000 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 -- 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.