Other ctld and ctladm

M

mir

Hi list,

I am currently trying to write a Perl module for automatic creation and removing on LUNs using ZVOL as backing store using a combination of ctladm and ctld. I have more or less solved all issues but I have a problem with three issues:
  1. LUNs created with ctladm do not survive a reboot
  2. It seems the only way to expose LUNs via iSCSI created with ctladm is to add them to ctl.conf and then reload ctld
  3. It seems the only way to remove LUNs via iSCSI is to remove them
    from ctl.conf and then reload ctld
Have I missed something or is this the only way?

I would love to be able to write directly to the daemon and then only update ctl.conf for the purpose of reboot.

[ Follow the forum's rules and guidelines -- Mod. ]
 
Last edited by a moderator:
You are right in your points. The iSCSI target is in half implemented by the user-level ctld() daemon, so you can not avoid using it. Technically you should be able to create iSCSI LUN for an/the already existing iSCSI target by passing the right arguments to ctladm(), but that API is never documented, and may change without warnings.

So I think that the proper way for you is to update ctl.conf and make ctld() reload it by sending it a SIGHUP signal, or via service ctld reload. reload unlike the restart should be transparent for unaffected LUNs.
 
I have found another limitation. It seems you are only allowed to configure a total of 255 LUNs which means you can have maximum 255 targets containing one LUN each at one extreme to one target containing 255 LUNs at the other extreme. This is quite limiting giving a large ZFS based storage array equipped with dozens of disks. I could easily understand if the limit was 255 LUNs or less for each target but having an upper global limit of 255 targets/LUNs seems appropriate to me.
 
You are right again: there is a global 256 LUNs and 128 iSCSI targets limitation in CTL now. Both values are build-time defines (CTL_MAX_LUNS and CTL_MAX_PORTS). They can be increased by modifying sources and rebuild, if needed, but at this point that is not free for RAM usage. To raise the defaults some optimization or at least estimation work should be done first.
 
Hi,

I've got related problem. I want to ask question about "not free for RAM usage".
So I've got software which changes exported iSCSI targets 100 times in a minute (it's forstress test purpose). I'm working on FreeBSD 12.0 RELEASE.
Export procedure is following:
- remove one of already exported iSCSI target by deleting "lun" and "target" record from /etc/ctl.conf file (I work with JSON format of ctl.conf)
- add new iSCSI target by adding "lun" and "target" records
- service ctld reload

I noticed that while repeating this procedure RAM usage of ctld increase continuously (I've monitored RES column in top). If I repeat this procedure many times ctld goes out of swap.
So my question is this issue already known and is it way to handle it?

Regards,
Patryk
 
You must log in or register to reply here.
Back
Top