ZFS iSCSI ctl reload issues

C

carlossrp

Hi FreeBSD Forum,

I'm building a backup solution for 2 Windows Servers that's basically present some iSCSI zvol-backed disks to one server, snapshot them every 15 minutes and then clone some of these snapshots to the other server on demand.

Everything was fine until I reached about 80 luns in ctl.conf. At this point, the time to reload the ctl service ( service ctld reload) started to grow linearly with the lun number.

For example, on the very beginning (when ctl.conf had only one LUN to the "source" server and one LUN to the "target" server) it took about 20 seconds to "refresh" a LUN (destroy and clone new LUN from a given snapshot to the "target" server), but now it's taking about 7 minutes with ~180 LUNs.

Issuing cltd reload is instantaneous, but the new disk takes this time to appear at "diskmgmt.msc" on Windows.

Any clues of where to begin troubleshooting?

Thanks in advance!
 
Some update,

I managed to track the problem source:

When I issue service ctld restart, besides refreshing information of the only changed lun, ctld refreshes for all luns, as could be seen in debug.log sample:
Code: 
...
Sep 27 23:06:38 foobar ctld[543]: modifying lun "iqn.foobar:ws2k12a,lun,82", CTL lun 161
Sep 27 23:06:38 foobar ctld[543]: modifying lun "iqn.foobar:ws2k12a,lun,83", CTL lun 162
Sep 27 23:06:38 foobar ctld[543]: updating port "pg0-iqn.foobar:ws2k12b"
Sep 27 23:06:38 foobar ctld[543]: updating port "pg0-iqn.foobar:ws2k12a"
Sep 27 23:06:38 foobar ctld[543]: not listening on portal-group "default", not assigned to any target

Here is a sample of my ctl.conf file:

Code: 
maxproc 0

debug 1

portal-group pg0 {
        discovery-auth-group no-authentication
        listen 192.168.0.100
        listen [::]
}

target iqn.foobar:ws2k12a {
        auth-group no-authentication
        portal-group pg0

        lun 1 {path zvol/tank/stages/ws2k12a/foo option pblocksize 0}
        lun 2 {path zvol/tank/stages/ws2k12a/bar option pblocksize 0}
        lun 5 {path zvol/tank/stages/ws2k12a/foobar option pblocksize 0}
        lun 6 {path zvol/tank/stages/ws2k12a/foobaz option pblocksize 0}
        ...
       
}

target iqn.foobar:ws2k12b {
        auth-group no-authentication
        portal-group pg0

        lun 2 {path zvol/tank/tests/ws2k12b/foo option pblocksize 0}
        lun 4 {path zvol/tank/tests/ws2k12b/bar option pblocksize 0}
        lun 5 {path zvol/tank/tests/ws2k12b/foobar option pblocksize 0 option unmap on}
        lun 6 {path zvol/tank/tests/ws2k12b/foobaz option pblocksize 0 option unmap on}
        ...
       
}

Lun index are not in sequence because of a bug in one script I'm developing to automate my tests.

I think this might be happening because I'm not creating the luns with ctladm, but I'm having a hard time with it.

Basicaly, when it's needed to "refresh" lun 2 of ws2k12b, for example, I delete this line from ctl.conf, reload ctld service, destroy the zvol with zfs destroy tank/tests/ws2k12b/foo, clone a new zvol with zfs clone tank/stages/ws2k12a/foo@today tank/tests/ws2k12b/foo, write the line back to ctl.conf and then reload ctld service again. After that, running update-hoststoragechage on ws2k12b reflects the lun "refresh" process.

All zvols are formatted with NTFS, on Windows.

Any suggestions on how to make this lun config "static" and only reloading the modified lun?

Thanks!
 
You must log in or register to reply here.
Back
Top