Date: Mon, 27 Dec 1999 17:21:35 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Proposed patch to fix VN device (again) Message-ID: <199912280121.RAA35049@apollo.backplane.com> References: <9890.946343423@critter.freebsd.dk>
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 ?
#9 0xc023c5b3 in trap ()
#10 0xc014b862 in devsw ()
#11 0xc017fa4a in vn_isdisk ()
#12 0xc018e1f3 in spec_strategy ()
#13 0xc020eb42 in flushchainbuf ()
#14 0xc0202e1e in swap_pager_strategy ()
#15 0xc020e675 in vm_pager_strategy ()
#9 0xc023c5e3 in trap ()
#10 0xc014b862 in devsw ()
#11 0xc018e26e in spec_strategy ()
#12 0xc020eb72 in flushchainbuf ()
#13 0xc0202e4e in swap_pager_strategy ()
#14 0xc020e6a5 in vm_pager_strategy ()
#9 0xc023c5c3 in trap ()
#10 0xc018e23f in spec_strategy ()
#11 0xc020eb52 in flushchainbuf ()
#12 0xc0202e2e in swap_pager_strategy ()
#13 0xc020e685 in vm_pager_strategy ()
:> 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."
Ummm. The VN device is not a filesystem, it's a 'disk'. The UFS
filesystem does not recursively VOP_BMAP down into the underlying
media so implementing VOP_BMAP in VN would not help.
We could implement our own set of device vectors but it would be rather
pointless since specfs's device vectors do everything we want.
And, in anycase, I am not going to spend hours putting together a long
involved patch when a simple short patch suffices. If you want to
spend the time to come up with your own patch (that doesn't screw the
pooch in regards to cluster performance!), then I'm all ears, otherwise
this patch is what is going to go in for the 4.0 release.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199912280121.RAA35049>