Re: [Iscsitarget-devel] scsi_id/scsi_sn and vpd 83 type 8h

[Ross S. W. W. <RW...@me...>]

Chris Siebenmann [mailto:ck...@cs...] wrote:
> 
> | 3) For backwards compatibility we could generate the 64-bit
> | hash from the user supplied scsi_id and simply ignore the
> | user supplied scsi_sn, or generate the hash from both the
> | scsi_id and scsi_sn. For the auto-generated scsi_sn we
> | should continue to use the IQN and LUN combo.
> 
>  As a sysadmin who is currently explicitly specifying scsi_sn (and
> scsi_id), my reaction to this idea is unprintable. If my config file
> explicitly specifies scsi_sn and a new version of IET generates any
> changes in the value that iSCSI initiators see, I have potentially
very
> serious problems. I do not want to find out what bits of our
fileserver
> initiators (if any) were using and counting on the old value, and what
> they will make of the new value and do to terabytes of visible storage
> as a result. At a minimum this HUGELY complicates any potential
upgrade
> in IET versions (and in testing for said upgrade).

First of all, we would never change the current branch. 1.4 will
be as it is. This will only appear in 1.5 and everyone will have
time to test out the new code and fix their environment prior to
deployment.

The SN/ID should have little impact if the storage environment
is shutdown before hand. As it is typical in real-world to have
both hard drives and arrays field upgraded which would carry
new SNs. The SN is really used in multi-pathing and these tables
are built every time the system starts. It's changing these
while the initiator is running that causes a problem.

> | 2) This 64-bit number can be generated using a variable
> | sized general hashing function such as FNV instead of MD5.
> | This would allow us to shed a lot of cypto compatibility
> | patches as a nice bonus.
> 
>  Please allow sysadmins to specify this value explicitly instead of
> deriving it from a hash function unless you can absolutely *prove* the
> absence of a hash collision (not merely say 'it is very unlikely').
> Very unlikely may eat terabytes of disk space some day as ZFS and
> Solaris multipathing says 'same serial number, clearly the same disk'.

There is always the possibility of a collision, but as long
as the probability is 1 in a LOT larger then any storage
server can have volumes to export then there should be a
rare problem.

The FNV hash is used in DNS, a multitude of RDBMS and other
commercial software, so it has proven itself.

-Ross
______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.