<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 September 2016 at 16:24, Nikita Konovalov <span dir="ltr"><<a href="mailto:nkonovalov@mirantis.com" target="_blank">nkonovalov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>From Sahara (and Hadoop workload in general) use-case the reason we used BDD was a complete absence of any overhead on compute resources utilization. </div><div><br></div><div>The results show that the LVM+Local target perform pretty close to BDD in synthetic tests. It's a good sign for LVM. It actually shows that most of the storage virtualization overhead is not caused by LVM partitions and drivers themselves but rather by the iSCSI daemons.</div><div><br></div><div>So I would still like to have the ability to attach partitions locally bypassing the iSCSI to guarantee 2 things:</div><div>* Make sure that lio processes do not compete for CPU and RAM with VMs running on the same host.</div><div>* Make sure that CPU intensive VMs (or whatever else is running nearby) are not blocking the storage.</div></div></blockquote><div><br></div><div>So these are, unless we see the effects via benchmarks, completely meaningless requirements. Ivan's initial benchmarks suggest that LVM+LIO is pretty much close enough to BDD even with iSCSI involved. If you're aware of a case where it isn't, the first thing to do is to provide proof via a reproducible benchmark. Otherwise we are likely to proceed, as John suggests, with the assumption that local target does not provide much benefit. <br><br>I've a few benchmarks myself that I suspect will find areas where getting rid of iSCSI is benefit, however if you have any then you really need to step up and provide the evidence. Relying on vague claims of overhead is now proven to not be a good idea. </div></div>
</div></div>