The fileio backing store driver is the way you would accomplish this. Consistency is only a concern if you choose to enable writeback caching (or as targetcli refers to it, "buffered mode") on the fileio backstores.
Unbuffered mode is the default for just about every targetcli implementation on any distro, as suggested by Datera itself. This shouldn't be a big deal.
However, if you need to force unbuffered mode for a particular backing object (and perhaps you should just to be safe), you can specify so thusly:
/backstores/fileio/test_name> set attribute buffered=False
As for addressing the issue of block size, you may also freely edit the block_size attribute for a particular fileio backing store object:
/backstores/fileio/test_name> set attribute block_size=4096
You can use fileio backstores to address thin LVM2 (or really any other block device) while changing nearly any setting, while the block or iblock backstores are optimized to pass devices and their hardware properties "directly" to initiators. Block should perform better than fileio, as the implementation is leaner - it just lacks features like this because of that lean implementation. If you don't require setting these parameters, "block" should be used for block devices.