Cyril Plisko wrote:
> Can we do something similar to NFS case, where sharenfs can be
> "on", "off", or something else, in which case it is a list of options ?
> Would this technique be applicable to shareiscsi too ?
Absolutely. We would, however, like to be conservative about adding
options
only doing so when it meets a specific need. As you noted, there's no
real
requirement to be able to set the LUN.
...to be able to set the LUN *for iSCSI*. That would be more concise
formulation.
I wonder why you would like to be conservative. Can you please explain
your considerations ? How would it be different from NFS ? It seems that
in NFS case one can put whatever options she likes in "sharenfs="
attribute.
From my point of view I would like to be conservative to prevent the
addition of a cool new feature that six months down the road we find
that it's only used in one particular case. Once added it's difficult to
remove because of our backwards compatibility requirement.
Also can you please elaborate more on the hidden attribute ? Which
values would be stored there ? Maybe the idea was to put all the options
into that attribute, thus making the "zfs get" output prettier (iSCSI
options
tend to have massive character count).
In that case why not to make something similar with NFS too ?
The target daemon stores the IQN name which is about 60 characters, the
GUID which is 32 characters, the emulation type, plus a few other
miscellaneous bits of information. The zfs command goes through some
effort to determine the longest property name and value. It then
displays that information in uniform column widths. The iscsi property
value blows that out of the water.
--
----
Rick McNeal
A good friend will come and bail you out of jail...but, a true
friend will be sitting next to you saying, "Damn...that was fun!"
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
