From owner-freebsd-current Mon Dec 27 19:49: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 6A352153A6 for ; Mon, 27 Dec 1999 19:48:38 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id EAA17617; Tue, 28 Dec 1999 04:48:15 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: dg@root.com Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: Proposed patch to fix VN device (again) In-reply-to: Your message of "Mon, 27 Dec 1999 18:58:41 PST." <199912280258.SAA12518@implode.root.com> Date: Tue, 28 Dec 1999 04:48:15 +0100 Message-ID: <17615.946352895@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912280258.SAA12518@implode.root.com>, David Greenman writes: >There >seems to be some unstated architectural philosophy that needs to be stated >before any informed decision can be made about what is the right direction to >go in. The underlying problem is of course that struct buf is a conglomerate of "struct block_cache" and "struct io_request", and in the cases where you need only the latter functionality you still have to respect all the conventions of the former. This issue leads to complexity and hacks in all code that needs to splite a io operation: vinum, ccd, swap_pager and disk_slice/label. For this reason the swap-pager has a bogus vnode: (swapdev_vp) to hang buffers from. This vnode even more bogusly uses spec_vnodeop_p for its vop[], and at the far end of that vop[] it used to abuse /dev/drum to get things done. If we want to maintain the presently unused generality of the chainbuf routines (they are currently only used in the swap-pager), then the fix is to add a real vop[] to the bogus swapdev_vp so that VOP_STRATEGY correctly end up in swstrategy() for swap device buffers. If we accept that the chainbuf routines are of limited utility, we can simply s/VOP_STRATEGY/swstrategy/ in the flushchain procedure. The reason why /dev/drum should not be brought back is that it isn't a device and it shouldn't be made one. In particular it should not made one to paste over a bogus vnode, that would be a step backwards. If we want to *really* fix the problem, we should introduce a bop[] function vector on struct buf. Kirk already (almost) did this: struct bio_ops. This bop[] would be where code would find the strategy, bwrite* and other operations on the buffer without knowing if the buffer has a dev_t, a dev_t + a vnode, only a vnode or neither associated with it. This fix is out of scope for the present problem, and certainly not a 4.0 item. This fix will be needed before we can put a non-device backed storage layer under UFS. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message