Darren, > John Forte wrote: >> This 'pins' the PGR data to a single Solaris host, even though a >> ZVOL or >> ZVOLs can be exported from the current node, imported on another >> node. >> There is no room in the ZVOL itself, as the iSCSI Client own 100% >> of the >> blocks in a ZVOL. There is little remaining space in the 'iscsi- >> options' >> ZVOL property, as other iSCSI properties consume ~1000 bytes, of a 2K >> limit, and PGR data can be 1000s or 10,000s of bytes in size, >> depending >> on the number of nodes in a clustering solution. > > The ZFS dataset property mentioned here is the hidden iscsioptions > property right ?
Yes. > So why not use multiple zap objects to store the PGR data (that > gives a lot more scope since now you have a list of name=value > pairs) like is already done for the ZFS delegation data. Doing this causes an iSCSI Target Daemon architecture / implementation violation. SCSI-3 PGR operations are SCSI CDB data path operations, invoked by one or more iSCSI Initiators. Interaction between the iSCSI Target Daemon and ZFS, specific to the iscsioptions property is a control path operation. During initIal prototype testing, crossing over from the data path to control path to store or retrieve PGR data caused hangs within daemon. > Having some of the data inside the ZFS dataset and some of it in > plainfiles (even if they are stored in ZFS) seems like a recipe for > getting things out of sync to me. Why is it okay for PGR data not > to be tightly tide to the ZVOL yet all the other iscsi options > are ? In fact the rationale above suggests the desire is that it > should be in the same ZFS dataset as the ZVOL. Given the hang concern outlined above, keeping ZVOL I/O and PGR I/O within the data path side of the iSCSI Target Daemon mitigates risk, is essentially identical to what is done today, where PGR data is now being written into /etc/iscsi/... > Now having said that I can see how this case can work just fine in a > tightly controlled environment. If there is a time to market issue > then I can grudgingly approve of this case as specified with one > small request that the SCF option be private and a plan is put in > place to investigate putting the PGR data with the ZVOL (either a > zap object or something else appropriate). Setting a PGR base directory is a tightly controlled environmental variable. If needed, it would be set once, and not changed. In regards to putting into place a plan to investigate other options, the iSCSI Target Daemon's future is limited due to its replacement with a new iSCSI Target in COMSTAR. That said, there is more development work to be done in COMSTAR before the iSCSI Target Daemon starts its EOL process, and a new PGR implementation is one of these development tasks. > > -- > Darren J Moffat Jim Dunham
