Date: Sat, 18 Apr 2015 23:12:11 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Julian Hsiao <madoka@nyanisore.net>, "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org> Subject: Re: Bhyve storage improvements (was: Several bhyve quirks) Message-ID: <5532BA9B.80600@FreeBSD.org> In-Reply-To: <5522EEE0.5010807@FreeBSD.org> References: <5522EEE0.5010807@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06.04.2015 23:38, Alexander Motin wrote: >> I had some time to try it out today, but I'm still having issues: > > I've just made experiment alike to your with making bhyve to work on top > of GEOM device instead of preferable "dev" mode of ZVOL. And I indeed > reproduced the problem. But the problem that I see is not related to the > block size. The block size is reported to the guest correctly as 4K, and > as I can see it works as such at least in FreeBSD guest. > > The problem is in the way how bhyve inter-operates with block/GEOM > devices. bhyve sends requests to the kernel with preadv()/pwritev() > calls, specifying scatter/gather lists of buffer addresses provided by > the guest. But GEOM code can not handle scatter/gather lists, only > sequential buffer, and so single request is split into several. The > problem is that splitting happens according to scatter/gather elements, > and those elements in general case may not be multiple to the block > size, that is fatal for GEOM and any block device. > > I am not yet sure how to fix this problem. The most straightforward way > is to copy the data at some point to collect elements of scatter/gather > list into something sequential to pass to GEOM, but that requires > additional memory allocation, and the copying is not free. May be some > cases could be optimized to work without copying but with some clever > page mapping, but that seems absolutely not trivial. I've committed the workaround to FreeBSD head at r281700. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5532BA9B.80600>