Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Dec 1999 04:48:15 +0100
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        dg@root.com
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, freebsd-current@FreeBSD.ORG
Subject:   Re: Proposed patch to fix VN device (again) 
Message-ID:  <17615.946352895@critter.freebsd.dk>
In-Reply-To: Your message of "Mon, 27 Dec 1999 18:58:41 PST." <199912280258.SAA12518@implode.root.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17615.946352895>