ctl.conf / iscsi docs and best practices
- Reply: Michael Jung : "RE: ctl.conf / iscsi docs and best practices"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 14 Mar 2022 18:47:35 UTC
Looking at diving deeper into FreeBSD as an iscsi target and initiator, but more so as a target server. Looking at the handbook, there are not a lot of docs there and the sample ctl.conf entries dont really follow the style of the example ctl.conf file generated by something like TrueNAS. Are there any better FreeBSD docs out there ? Anyone have any decent go to docs around iscsi in general that are good primers as well ? My goal is to serve up storage for a bunch of Linux KVM initiators with the iscsi targets on FreeBSD being zvols. e.g. in TrueNAS, I see it define a bunch of individual LUNs and then targets as so. lun "freebsd2" { ctl-lun "1" path "/dev/zvol/tankstripe/freebsd2" blocksize "512" serial "000743299890001" device-id "iSCSI Disk 000743299890001 " option "vendor" "TrueNAS" option "product" "iSCSI Disk" option "revision" "0123" option "naa" "0x6589cfc000000c330e3ddde42a36408a" option "insecure_tpc" "on" option "rpm" "1" } lun "freebsd3" { ctl-lun "2" path "/dev/zvol/tankstripe/freebsd3" blocksize "4096" serial "000743299890002" device-id "iSCSI Disk 000743299890002 " option "vendor" "TrueNAS" option "product" "iSCSI Disk" option "revision" "0123" option "naa" "0x6589cfc0000001cd46c021f21b31d0cc" option "insecure_tpc" "on" option "rpm" "1" } Then define more LUNs in the targets that reference the above LUNs target "iqn.2005-10.org.freenas.ctl:freebsd2" { alias "freebsd2" portal-group "pg1" "ag4tg2_2" lun "0" "freebsd2" } target "iqn.2005-10.org.freenas.ctl:freebsd3" { alias "freebsd3" portal-group "pg1" "ag4tg3_3" lun "0" "freebsd3" } So the lun that refers to the block of storage also has a ctl-lun that seems to be uniq. What is the purpose of that ? Same with serial #s and Device-IDs. Are these merely informational or are they a requirement for something ? If multiple initiators are to have sessions to the target, with only one actively writing to it, are there any special options I need to set ? I also noticed in ctladm are several cache sync options. My go - to zfs replication software is zrepl which has hooks that can be fired before and after a snapshot. Do I want to send some sort of cache flush command to the target ? Or is that the guest OS' responsibility to do a sync that that the snapshot is coherent as possible. Thanks for any pointers. ---Mike