Re: [Xen-devel] xl block-attach vs block-detach

[Joseph Glanville <joseph.glanville@xxxxxxxxxxxxxx>]

On 3 March 2012 16:25, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> Please don't top post, it destroys the flow of the conversation.

My apologies, GMail is a very irritating client.

>
> On Fri, 2012-03-02 at 22:54 +0000, Joseph Glanville wrote:
>> Hi,
>>
>> As I understand it prefering tapdisk over loop+blkback has never been
>> for performance reasons historically. (tapdisk2:aio does however
>> exhibit very good performance)
>> The primary reason that tapdisk was always recommended over file: is
>> that the Linux file cache does very interesting things to your data
>> and sync is returned to the blkback backend much sooner than the data
>> actually resides safely on disk (which can sit in the linux disk cache
>> for a sizeable amount of time if they machine has alot of ram).
>
> Are you suggesting that the loop device doesn't support O_DIRECT and
> will leave stuff dirty in the page cache even when direct access is
> used? That is worth knowing!

As far as I am aware this is the case. It doesn't support O_DIRECT in
any capacity.
There was some patches submitted to the list a very long time ago ( I
could probably find them if I tried) but they were knocked back by
upstream.
It is possible this could have changed so I will take a glance at the
source of loop.c tonight to see if that is actually the case.

>
>> Unfortunately changing the default behavior to tapdisk
>
> What exactly needs changing?

I was suggesting that tapdisk would be a much safer default in terms
of data integrity for the above reason that the loop driver doesn't
support O_DIRECT.

>
>>  probably isn't
>> viable at this time for a number of reasons - not least of which is
>> the fact it is yet to be included in mainline.
>
> tapdisk is not going to be included in mainline. The kernel side is
> deemed to be non-upstreamble.
>
> Someone is working on a fully userspace version of bkltap which we hope
> will be ready soon.

That is unfortunate, would you mind pointing me in the direction of
the pure userspace version?
Would the performance be considerably worse than the current implementation?

>
> Ian.
>
>> However it would definitely be preferable in the long term - atleast
>> from the perspective of data integrity and principle of least
>> surprises.
>>
>> Just my 2c.
>>
>> Joseph.
>>
>> On 3 March 2012 04:37, Stefano Stabellini
>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > On Fri, 2 Mar 2012, Stefano Stabellini wrote:
>> >> On Fri, 2 Mar 2012, Jan Beulich wrote:
>> >> > > What would be the rationale behind using blkback+loop for "file:"?
>> >> > > Backward compatibility?
>> >> >
>> >> > Yes.
>> >> >
>> >> > > Do you think it might break something for users if we change the 
>> >> > > backend
>> >> > > from xend to xl?
>> >> >
>> >> > This cannot be excluded, particularly because (just like me here)
>> >> > users tend to do things you didn't expect them to when you write
>> >> > the code.
>> >>
>> >> I see your point but actually that is quite an obvious bug, not a very
>> >> subtle one that only happens in strange user configs.
>> >>
>> >
>> > Scratch that: I have just tried on Linux 3.3 and the performance of
>> > blkback with loopback is very good. We should use it whenever we can.
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@xxxxxxxxxxxxx
>> > http://lists.xen.org/xen-devel
>>
>>
>>
>
>

All of that being said it is still relatively OK to leave blkback+loop
as the default as the majority of users I would assume use actual
block devices (though I could be horribly wrong here).
All documentation and best-practices on the wiki outline this in detail.

Joseph.

-- 
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel