RE: iScsi:

[Black_David@emc.com]

> Well, let's take a case 
> where you have one target and many initiators connected that target
> 
> And as iScsi is at block level, so if more than one initiator have
requested
> to write at the same block address at the same time at the same target 
> this can create synchronization problems, don't you think?
> 
> Shouldn't you give an option like most other protocols like NFS does,
> where you have a separate optional layer for locking/synchronization...
> 
> Don't you think this should be handled by iScsi??

NO!!!  Believing that SCSI should operate like NFS is a major mistake;
they are completely different classes of protocols solving very different
problems.  Adding a locking/synchronization layer would introduce an
immense amount of cruft to the Target implementations.  When data is
shared over SCSI, the coordination generally happens at a coarser level
(e.g., persistent reservations) or at a higher level (e.g., some sort
of distributed filesystem code, two examples are Tivoli's SANergy and
EMC's HighRoad).  As John Hufferd wrote:

> I think you need to understand how SCSI on Shared Devices work.  If you do
> not coordinate either via a Shared File System or Shared Data Base, or
SCSI
> Reserves, you clearly have a problem.  But this is a well known issue and
> has been solved years ago with multiple SCSI Bus connections to the same
> Storage Controller, and currently applies to Fiber Channel as well as
> iSCSI.  Nothing new is needed in the iSCSI protocol.

I completely agree with John.  

Beyond this, if one wants to make this sort of major functional change
to SCSI, T10 is the right forum - this type of work cannot and will not be
done in the IETF, if for no other reason than the IPS WG charter has
wording that forbids it.

A strong architectural understanding of SCSI is a major prerequisite to
attempting to make this sort of change.  Within the past year or so, there
was a proposal made to T10 to do this sort of thing for SCSI in general,
and (IMHO) the proponents' lack of this architectural understanding is
one of the reasons it never went anywhere.  I would also recommend looking
at the work on the OSD SCSI command set that is in progress in T10 (which
is digging in a related area), but I would caution that there appears to
be a distinct lack of enthusiasm and interest in implementing that command
set.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------