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. [email protected] schrieb am Mittwoch, 26. Mai 2021 um 19:07:20 UTC+2: > 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 > > > > > > On Wed, May 26, 2021 at 10:33 AM 'H. Giebels' via open-iscsi < > [email protected]> wrote: > >> I think I've got it. It is the emulate_tpu parameter on the target side. >> Needs some more confirmation, though >> >> H. Giebels schrieb am Mittwoch, 26. Mai 2021 um 15:26:39 UTC+2: >> >>> >>> 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 >>> >>> >>> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/open-iscsi/086c0e6e-4df9-409c-80a4-d611fd36a363n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/open-iscsi/086c0e6e-4df9-409c-80a4-d611fd36a363n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/d54dddca-dd0a-40a1-a698-a3107445beb5n%40googlegroups.com.
