[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 02.03.12 at 15:35, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> On Fri, 2 Mar 2012, Jan Beulich wrote:
>> >>> On 02.03.12 at 14:49, Stefano Stabellini 
>> >>> <stefano.stabellini@xxxxxxxxxxxxx>
>> wrote:
>> > On Fri, 2 Mar 2012, Ian Campbell wrote:
>> >> > And if using blkback, why not (as in xend) via loop devices?
>> >> 
>> >> Support for block device script= in xl/libxl is on the 4.2 blocker list,
>> >> this feature would re-enable the loop+blkback case -- I think this would
>> >> be a better option than blktap* or qdisk once it becomes available.
>> > 
>> > Of course we need to make sure that blkback with loop devices performs
>> > well before doing that, and it was certainly not the case in my last tests.
>> No - no policy should be involved here: If file:/ is specified, one should
>> get blkback alone (no tap, qdisk, or what not. If another protocol was
>> specified, that one should be used. Only if guessing is needed, some
>> sort of heuristic (into which performance considerations may play) will
>> (naturally) be required.
> Let's suppose we find out that blkback+loop is slower than qdisk and
> that block-attach/detach work well with qdisk by the time of the next
> release.
> What would be the rationale behind using blkback+loop for "file:"?
> Backward compatibility?


> 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.

> On the other hand do you think that using qdisk with the new disk syntax
> introduced with xl is reasonable because users are not supposed to make
> any assumptions there?

Perhaps yes.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.