[Gluster-users] Block storage with Qemu-Tcmu
pkalever at redhat.com
Mon Nov 7 09:40:26 UTC 2016
I am planning to write a short blog to answer few similar questions
that I received after posting this blog.
Is iSCSI stack obligatory for block store ?
Answer is No.
It basically depends on the use case and choice. If we can run/manage
target emulation on the client side, we don't have to bring iSCSI
stack into picture.
We simply export LUN using a loopback device i.e after creating the
back end with qemu-tcmu storage module, we can directly export the
target via loopback instead of iSCSI.
So In this case we don't see overheads with iSCSI layers, but IMO
overhead with iSCSI can be very minimal, may be I need the performance
numbers to prove (will spin a benchmark soon)
I have done some basic benchmarking taking baseline as Fuse mount and
target as iSCSI exposed target via tcmu-runner, you can find them at
You can find more bechmark's at , the commit messages should
explain you the configurations.
Hope that answers most of your questions :)
On Mon, Nov 7, 2016 at 2:23 PM, Gandalf Corvotempesta
<gandalf.corvotempesta at gmail.com> wrote:
> Il 07 nov 2016 09:23, "Lindsay Mathieson" <lindsay.mathieson at gmail.com> ha
>> From a quick scan, there doesn't seem to be any particular advantage
>> over qemu using gfapi directly? Is this more aimed at apps that can't
>> use gfapi such as vmware or as a replacement for NFS?
> Dump question: why should i use a block storage replacing nfs?
> Nfs-ganesha makes use of libgfapi, block storage does the same but also need
> the whole iscsi stack so performance could be lower
> If i don't need direct access to a block device on the client (in example
> for creating custom FS or LVM and so on), the nfs ganesha should be a better
> approach, right?
> Anyone compared performances between:
> 1. Fuse mount
> 2. Nfs
> 3. Nfs ganesha
> 4. Qemu direct access via gfapi
> 5. Iscsi
More information about the Gluster-users