less than whole lengths
rsnively at Brocade.COM
Wed Mar 13 15:40:25 PST 2002
* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
Fortunately, none of the below.
All it means is that when you divide a data transfer into
multiple sequences (pdu's in iSCSI-ese), all but the last
are required to be multiples of 8 bytes. The block size
can be any value, since sequence sizes are not required to
be related to block boundaries. In addition, the
total length can be any value, because there are no
limitations on the length of the sequence that transfers
the highest bytes in the string. Remember that the
sequences may be transferred in any order, depending upon
the agreements between initiator and target.
> -----Original Message-----
> From: Pat LaVarre [mailto:LAVARRE at iomega.com]
> Sent: Wednesday, March 13, 2002 1:30 PM
> To: t10 at t10.org
> Subject: RE: less than whole lengths
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Pat LaVarre" <LAVARRE at iomega.com>
> This doesn't yet preclude copying in x24 bytes of op x12
> Inquiry data, does
> This just says the block size for block data out now has to
> be a multiple of
> 8, precluding, for example the x 914 91C 924 (aka 2324, 2332,
> 2340) that
> rumour says some SFF-8090 folk like?
> Or does this also tell us that, say, ModeSelect data copied
> out has to have a
> length that is a multiple of 8?
> Sorry I'm so clueless re FC-PLDA, thanks again in advance.
> x4402 Pat LaVarre p.lavarre at ieee.org
> >>> Robert Snively 03/13/02 02:20PM >>>
> Already done.
> See FC-PLDA, clause 8.2.2
> The DATA_RO parameter in the FCP_XFER_RDY IU on
> write type operations for disk devices shall
> be a multiple of 8 bytes.
> >>> ...
> > 512 2048 2056 2324 2332 2336 2340 2352 2368 2448
> Ouch. For these 10 block sizes I think I see the GCD (greatest common
> divisor) is 4. If we say 8 we lose 2324, 2332, 2340. If we
> say x10 we also
> lose 2056. Ouch.
> x200 = 512 = 1 * 2**9
> x800 = 2048 = 1 * 2**11
> x808 = 2056 = 1 * 2**3 * 257
> x914 = 2324 = 1 * 2**2 * 7 * 83
> x91C = 2332 = 1 * 2**2 * 11 * 53
> x920 = 2336 = 1 * 2**5 * 73
> x924 = 2340 = 1 * 2**2 * 3**2 * 5 * 13
> x930 = 2352 = 1 * 2**4 * 3 * 49
> x940 = 2368 = 1 * 2**6 * 37
> x990 = 2448 = 1 * 2**4 * 3**2 * 17
> SFF-8090 says:
> If supported, block sizes (see See Block Descriptor Block
> Sizes for Read on
> page 234.) shall include 2048 and may include 512, 2056,
> 2324, 2332, 2336,
> 2340, 2352, 2368, and 2448 bytes. The Table of Block Sizes
> for Read shows the
> implementation of the various block sizes.
> Table 158 - Block Descriptor Block Sizes for Read
> Size Readable block types
> 512 Mode 1 or Mode 2 Form 1 sectors divided into four blocks each.
> 2048 Mode 1, Mode 2 Form 1, or DVD
> 2056 Mode 2 Form 1 with subheader. Equivalent to Read CD, Flag = 50h.
> 2324 Mode 2 Form 2 with no subheader. Note: There is no
> mapping to Read CD, as
> the 4 spare bytes are not returned.
> 2332 Mode 2, form 1 or 2 data. The drive shall operate as
> specified for 2048
> byte blocks except: Both forms send 2332 byte blocks. Form 1
> blocks return the
> third layer ECC with the user data. Note: There is no mapping
> to Read CD, as
> the 4 spare bytes are not returned.
> 2336 Mode 2 data The drive shall operate as specified for
> 2048 byte blocks
> lengths. This mode will include all data, including Yellow
> Book Mode 2 sectors
> and Form 1 and Form 2. Equivalent to Read CD, Flag = 58h.
> 2340 All bytes except the synchronization field. Equivalent
> to Read CD, Flag =
> 2352 Audio or raw blocks. The drive shall operate as
> specified for 2048 byte
> blocks. Reads of data mode sectors shall return descrambled
> data. Equivalent
> to Read CD, Flag = F8h.
> 2448 or 2368 Audio or raw blocks with raw sub-channel. The
> drive shall not
> perform the data descrambling operation. Equivalent to Read
> CD, Flag = F8,
> Sub-channel data selection = 010b (2448) or Sub-channel data
> selection = 001b
> > -----Original Message-----
> > From: Pat LaVarre [mailto:LAVARRE at iomega.com]
> > Sent: Thursday, March 07, 2002 5:03 PM
> > To: t10 at t10.org
> > > It is just unfortunate (and a historical accident)
> > > that standard ... data is ... is not 32-bit aligned.
> > A accident nowadays looming larger is that so much standard
> > data is not 64-bit (8 byte) aligned e.g. the x24 bytes
> > commonly moved in by the cdb x 12 0 0 0 24 0
> > i.e. Inquiry for up to x24 bytes.
> > It will be fun to see if the people who have so successfully
> > resisted moving anything but N * 4 bytes will soon try
> > to move nothing but N * 8 bytes.
> > Often I've wished there was a way to be a Scsi device yet
> > still insist on never moving anything but N * K bytes,
> > where K was my block size, like Ata does.
> > Pat LaVarre
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10