Re: questions on the mapping in iSCSI

[julian_satran@il.ibm.com]

I sent the response to the list a while ago. But here I attach it again
and again Good Luck, Julo

----------------------------------


Julian Satran
21/07/2000 09:42

To:   ips@ece.cmu.edu
cc:
From: Julian Satran/Haifa/IBM@IBMIL
Subject:  Re: questions on the mapping in iSCSI  (Document link: Julian
      Satran - Mail)

Bill,

SRA's are returned by the target - the initiator only provides the
descriptors;
the idea is to let the target organize them as it sees fit (e.g., store the
strings only once even if they originate from different initiators).

I expect you would want to do as much work as possible and explore all
descriptors.
However finding out that a descriptor is bad can happen even after mapping.
I refrained in fact specifying when will the name-to-address mapping be
done (lazy or eager).

I assume that unmapping should not have any effect on outstanding I/O - but
I will make
a not to clarify this point.

Good luck with the implementation and thanks,
Julo

Bill Main <wmain@gis.net> on 21/07/2000 00:34:30

Please respond to bill.main@bigfoot.com

To:   ipSCSI list <ips@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  questions on the mapping in iSCSI




Folks-
    Been working on trial implementation of iSCSI as it seems to me the
easiest way to find loose threads in a new spec.

couple of items have showed up so far:

    Question with regard to the mapping. I see latest spec descriptors
that move from initiator to host but the response to mapping has little
data in it other than status. Who generates the SRA's for the host to
use.

Are the SRA's part of the descriptor and the host is therefore informing
the target what LUN id it will use for this "view"?

Or should the SRA be returned from the target to inform the host what
SRA to use to reach the desired view? If so the data layout needs
updating to accommodate this.

    Next, multiple descriptors are allowed in the map command. What
action should be taken if one is bad? Do the others and respond with
failure or disallow others from succeeding? or should we limit the map
command to single descriptor? I am thinking also of the poor sys admin
trying to fix a broken mount command.

    Next, on the unmapping. What happens when an unmapping is done and
outstanding IO's are pending on the device? in flight? Does the target
can them or let them complete?

    It is not clear, but I presume the response to the unmap occurs
after the IO's are either completed or aborted and abort is confirmed by
the hardware at the target end. Is this correct?

    -Bill



___________________________

Bill Main <wmain@gis.net> on 21/07/2000 17:07:52

Please respond to bill.main@bigfoot.com

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  questions on the mapping in iSCSI




Julian-
     I have not had any responses to the spec question so I thought I would
ask the author directly.

     I do have to say however that the state table on this has come
together
very nicely in general. Although I am not done yet, it seems be a well
laid out spec. My compliments!

     -Bill

Folks-
    Been working on trial implementation of iSCSI as it seems to me the
easiest way to find loose threads in a new spec.

couple of items have showed up so far:

    Question with regard to the mapping. I see latest spec descriptors
that move from initiator to host but the response to mapping has little
data in it other than status. Who generates the SRA's for the host to
use.

Are the SRA's part of the descriptor and the host is therefore informing
the target what LUN id it will use for this "view"?

Or should the SRA be returned from the target to inform the host what
SRA to use to reach the desired view? If so the data layout needs
updating to accommodate this.

    Next, multiple descriptors are allowed in the map command. What
action should be taken if one is bad? Do the others and respond with
failure or disallow others from succeeding? or should we limit the map
command to single descriptor? I am thinking also of the poor sys admin
trying to fix a broken mount command.

    Next, on the unmapping. What happens when an unmapping is done and
outstanding IO's are pending on the device? in flight? Does the target
can them or let them complete?

    It is not clear, but I presume the response to the unmap occurs
after the IO's are either completed or aborted and abort is confirmed by
the hardware at the target end. Is this correct?

    -Bill