8

I'm creating logical volumes for export via targetcli (iSCSI).

I'm using lvm's thin provisioned volumes, e.g.

lvcreate -V 1T --thin -n vol_name storage/thin_pool

Then I add the created logical volume into targetcli's iblock backstore. The resulting device shows 4096 as get attribute hw_block_size

Due to lacking initiator support (VirtualBox) I need those LUNs to have 512-byte sectors. I'd like to avoid using fileio backstore (which supposedly allows setting sector size), for consistency reasons.

Is it possible to specify sector size during creation of the volume or assignment of the volume into backstore?

Spooler
  • 7,046
  • 18
  • 29
velis
  • 233
  • 2
  • 10

3 Answers3

7

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:

#> targetcli

/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.

Spooler
  • 7,046
  • 18
  • 29
  • Is there a documentation about what kinds of attributes are supported on the backstores? I couldn't find any list of supported attributes that I can set on the MAN page nor anywhere else. The only sites that I found when I google search `targetcli "block_size"` is this question and a Reddit thread. – user643011 Mar 28 '23 at 22:21
  • I found this in the source code: https://github.com/Datera/rtslib/blob/6fd0bbfc20947143eb2e4c3bfd34c65bf8551468/policy/backstore_iblock.lio – user643011 Mar 28 '23 at 22:31
  • `targetcli` is self-documenting, and is navigable like a file manager. Nodes are nested via a directory hierarchy. Each node or directory has a set of arguments that can be passed to it. The `help` command will display usable attributes for a particular path. So in your case, `help /backstores/fileio` should give you the answer you want. Increase directory depth as needed. – Spooler Mar 30 '23 at 20:10
  • No, in my testing it didn't work. Neither `help` in `/backstores/block/` nor `get` without parameter do list attribute descriptions. https://lore.kernel.org/target-devel/trinity-7a9a1e34-4702-4c7a-8012-e540eea4447b-1680090704891@3c-app-gmx-bs24/T/#u – user643011 Apr 03 '23 at 09:25
5

With regads to the question, the block size can be changed at time when the file system is to be created. Therefore, I believe, you should run mkfs.yourfs -b 512 /dev/mapper/<VGName>-<logical volume>where yourfs is type of your file system.

Community
  • 1
Mr. Raspberry
  • 3,918
  • 13
  • 32
  • 1
    There is no filesystem on the block device which is shared via iSCSI. Only the initiator (client) creates one – velis Dec 06 '16 at 19:15
  • 1
    I guess, you need to run this command on the server, where you creating and formatting logical volumes. – Stuka Dec 07 '16 at 09:45
0

I had big pain getting an LIO target LUN to be recognized by ESXi 6.5. I'm not overlaying LVM onto the virtual disk exposed from the RAID subsystem, just straight up use the 'targetcli' command to expose the virtual disk as an iSCSI LUN, to my ESXi host. (using a 'block' type backstore)

Being new hardware, the physical disks are 4096 sector sized. This exposed itself all the way up to the iSCSI subsystem on ESXi host, which successfully logged into the target, but refused to show a LUN device. (The ESXi log files clued me into its complaint about unsupported sector size.)

Once identified, this was readily solved with 'targetcli' util, with a 'set attribute block_size=512' command.

I did not have to switch to a 'fileio' backstore type! But note: it will not let you do this if the backstore is currently bound to an iscsi lun -- you have to break that bind (delete the lun), set the block_size, then recreate the iscsi lun.

I'm working with 'targetcli' command version 2.1.51, on RHEL 7.

Rick Sustek
  • 21
  • 1
  • This was helpful. Would be nice to tell people explicitly which targetcli path you found the particular block_size attribute you set, since you said you weren't using /backstores/fileio. I found one in /backstores/block, but it was already set to block_size=512, so I'm going to try making a zvol with volblocksize=4K. Thanks. – AveryFreeman Dec 25 '21 at 22:05