[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> wrote: > 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? 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. > 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |