RFC: Support for configuring file + loop device + target_core_iblock

[nefelim4ag]

Hi, AFAIK target_core_file module have a bad performance (compare to blockio) because it's use O_SYNC when open file and does not support ASYNC IO.
And does not matter we enable or disable WB cache for file, because it's can't improve random read performance.
Because of O_SYNC, kernel do a bad queue offload from iSCSI target to disks.
target_core_iblock does not have such problem and can only be used with only some types of devices, but pure block device (i.e. without LVM) can't provide some options like emulate_tpu & emulate-tpws (also it can't use simple write-through ram cache).
(With fs we can add deduplication and compression for LUN)

Some time ago loop device in kernel has been improved for support AIO and DIO: https://lwn.net/Articles/654701/
So stack like file + loop device + target_core_iblock can potentialy provide better performance then pure file + target_core_file (and i think better then target_core_iblock + block device because of some caching).

AFAIK at now kernel iSCSI guys working on TCMU stuff so i think no one will update fileio target module in near future for support AIO & DIO.

So my request is:
Can you add support to autoconfigure stack like file + loop device + target_core_iblock (and may be switch for on/off DIO for loop device)?

Yes i can do it by some scripting to get persistent loop device name and use targetcli for expose this loop to initiators, but i think what do this stuff in one place will be better and more predictable.

What you think about it?

Thanks.

P.S.
I already do some tests for compare pure target_core_file with target_core_iblock. target_core_file show a very bad performance (low iops and abnormal high latency) =(

With target_core_iblock i see (with iostat) some queue depth on exported device, but with target_core_file i see 1 request in queue in case with random read.