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 ? 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. 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. 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). -- Darren J Moffat
