David Greenman wrote:
> I've heard from both of you that you think the other is wrong. This isn't
> very helpful, however, in finding the correct solution. What I'd like to hear
> from both of you is the reasons why swap is better as a device, or not. 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 problem is that swapdev_vp needs to handle VOP_STRATEGY(), and swapdev_vp
is incorrectly being pointed at spec_vnops. Here is a proposed (UNTESTED!)
clean fix:
Index: swap_pager.c
===================================================================
RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v
retrieving revision 1.129
diff -u -r1.129 swap_pager.c
--- swap_pager.c 1999/11/22 15:27:09 1.129
+++ swap_pager.c 1999/12/28 03:22:08
@@ -199,6 +199,32 @@
static daddr_t swp_pager_meta_ctl __P((vm_object_t, vm_pindex_t, int));
/*
+ * Handle a VOP_STRATEGY() on swapdev_vp
+ */
+
+static int
+swapdev_strategy(ap)
+ struct vop_strategy_args /* {
+ struct vnode *a_vp;
+ struct buf *a_bp;
+ } */ *ap;
+{
+ struct buf *bp;
+
+ bp = ap->a_bp;
+ return swstrategy(bp);
+}
+
+vop_t **swapdev_vnodeop_p;
+static struct vnodeopv_entry_desc swapdev_vnodeop_entries[] = {
+ { &vop_strategy_desc, (vop_t *) swapdev_strategy },
+ { NULL, NULL }
+};
+static struct vnodeopv_desc swapdev_vnodeop_opv_desc =
+ { &swapdev_vnodeop_p, swapdev_vnodeop_entries };
+VNODEOP_SET(swapdev_vnodeop_opv_desc);
+
+/*
* SWP_SIZECHECK() - update swap_pager_full indication
*
* update the swap_pager_almost_full indication and warn when we are
@@ -329,7 +355,7 @@
swhash_mask = n - 1;
- n = getnewvnode(VT_NON, NULL, spec_vnodeop_p, &swapdev_vp);
+ n = getnewvnode(VT_NON, NULL, swapdev_vnodeop_p, &swapdev_vp);
if (n)
panic("Cannot get vnode for swapdev");
swapdev_vp->v_type = VBLK;
After this, flushchainbuf() on a bp that is bound to swapdev_vp should do
the right thing. There is still no need at all to redirect this via a fake
device.
I'll be testing this shortly, but I wanted to get an alternative in before the
arms race truely turned nuclear.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
