Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Dec 1999 02:10:23 +0100
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: Proposed patch to fix VN device (again) 
Message-ID:  <9890.946343423@critter.freebsd.dk>
In-Reply-To: Your message of "Mon, 27 Dec 1999 17:01:55 PST." <199912280101.RAA34874@apollo.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <199912280101.RAA34874@apollo.backplane.com>, Matthew Dillon writes:

>    First, you are confusing the underlying swap devices that we swapon on
>    with the parent swap device that controls them.  The parent swap device
>    needs to have a dev_t - it does not currently have one, and this is
>    the entry point that the buffers are going into.  The underlying swap
>    devices *already* have a dev_t.  My kernel crashes on a NULL bp->b_dev.
>    In fact, it also crashes on a NULL vp->v_rdev.

And where in the code does this crash happen ?

>    Second, the clustering done above the VN device is done by the 
>    filesystem and has no understanding of whether the underlying media
>    controlled by the VN device can itself be clustered in the same way.
>    When using swap as backing store what may appear to be clusterable
>    by the filesystem may actually *NOT* be clusterable when you get into
>    the swap device due to potentially non-contiguous mappings as well
>    as border-crossings between interleaved swap devices.

So you need to cluster all the way through the VN device ?  Obviously
clustering on just one side will not buy you anything.  Tough luck...

It sounds more and more like the mistake here is for VN to have a
specfs VOP vector on top, I think it needs its own VOP vector so
it can get hold of the VOP_BMAP function...

--
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?9890.946343423>