trimming iscsi luns?

[H. Giebels]

Hello,

not exactly sure, wether this is an issue of targetcli or open iscsi. The target lun is a sparse file, and I would like to be able to trim that lun to reclaim free space. Think thin volume on a file backend.

Now iscsiadm -m session shows me (non-flash), what I suppose is the reason, why I get an operation not permitted error when trying to so so.

The manpage talks about a flash node, but it is nowhere explained, what that is and wether this is related to flash storage at all. So maybe there is some documentation about the terms used?

But primarily I would like to know, wether the information about the trimability is a matter of the target advertising it or wether this has to be defined during creation of the lun on the client side (-o new).

Thanks

Hermann

[H. Giebels]

I think I've got it. It is the emulate_tpu parameter on the target side. Needs some more confirmation, though

[Donald Williams]

Hello, 

 It is also the OS/filesystem that must support the TRIM or UNMAP command.  I.e. in EXT4 you have to set the option 'discard' when mounting a volume to support TRIM/UNMAP feature. Using something like 'fsttrim' 

 If your backend storage is RAIDed then typically any SSDs are not presented as SSD/FLASH drives to the host. Physical drives are virtualized by the RAID controller and LUNs are presented to the host.  

  Once the TRIM/UNMAP command is sent  it's up to the backend storage device to handle that properly. 

 Open-iSCSI itself is the transport to the target from the OS.  It does not initiate TRIP/UNMAP or any other SCSI commands on its own.  It will pass along those SCSI commands the OS sends and send back all results. 

 Regards, 

Don 

 

 

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/086c0e6e-4df9-409c-80a4-d611fd36a363n%40googlegroups.com.

[H. Giebels]

Hello Don,

thanks very much for further elaborating on this. I completely forgot to mention, the taget side is lio / targetcli. Sorry for this.

Indeed I've got sidetracked by the non-flash notion of iscsiadm. But this refers to something else - probably to those mysterious flashnodes mentioned in the man page.

The target lun is a sparse file on a xfs filesystem (ontop of a md0 raid, but with trim enabled: raid456.devices_handle_discard_safely=Y)

The filesystem on the lun itself is f2fs. That does report discard capabilities already during mkfs time. At least, if -t=1 is specified.

Now I did a quick test with deleting half of the mounted lun, and indeed, the real size of beforementioned sparse file shrunk. Took a while, but finally I can confirm, setting emulate_tpu=1 on the target side does do the trick. If the backend supports it, of course.

I would suspect, it would work the same way for block based backstores (thin provisioned lvm, sparse zvols), but currently I have no means to verify this.

Just for future reference, as I have had troubles correctly interviewing google about this.