Re: Xen 4.2 Release Plan / TODO

["Jan Beulich" <JBeulich@suse.com>]

>>> On 19.03.12 at 12:33, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-03-19 at 11:25 +0000, Jan Beulich wrote:
>> >>> On 19.03.12 at 11:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >       * file:// backend performance. qemu-xen-tradition's qdisk is quite
>> >         slow & blktap2 not available in upstream kernels. Need to
>> >         consider our options:
>> >               * qemu-xen's qdisk is thought to be well performing but
>> >                 qemu-xen is not yet the default. Complexity arising from
>> >                 splitting qemu-for-qdisk out from qemu-for-dm and
>> >                 running N qemu's.
>> >               * potentially fully userspace blktap could be ready for
>> >                 4.2
>> >               * use /dev/loop+blkback. This requires loop driver AIO and
>> >                 O_DIRECT patches which are not (AFAIK) yet upstream.
>> 
>> I meant to ask already when this was first mentioned: What's the
>> reason for this requirement? Didn't we have blkback over loop running
>> fine for years? Or is this just a performance consideration (in which
>> case "requires" might be too strong a term)?
> 
> My understanding (which could well be totally bogus) was that the use
> of /dev/loop in this way was unsafe since pages were only committed to
> the dom0 page cache and not to the actual platter when success was
> reported to the guest. I think that is why many people used tap:aio:
> instead of file: (personally I use phy: almost exclusively so I could be
> talking rubbish).
> 
> Unless there are some loop patches in the classic-Xen patchset? I don't
> think there are though.

I know of none either.

Jan

> I don't know so much about the performance aspect. Stefano might be able
> to comment.
> 
> Ian.
> 
>> 
>> Jan
>> 
>> >               * Leverage XCP's blktap2 DKMS work.
>> >               * Other ideas?
>> 
>>