LongLBA bit in READ CAPACITY (10) command

Pat LaVarre LAVARRE at iomega.com
Wed Oct 2 05:57:25 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
Trying op x25 ReadCapacity10 before resorting to ReadCapacity16 might only work for awhile?
 
Already we have Windows with motherboards that in combination can't copy anything but multiples of 4 bytes e.g. http://members.aol.com/plscsi/20020328/oddwinme.txt
 
How long will it be before we have hosts that can't copy anything but multiples of 16 bytes?  Op x25 ReadCapacity10 implicitly involves copying in just 8 bytes.
 
Before then, we'll see the popular op x12 Inquiry for x24 bytes choke.  I wonder if that's popular enough to keep people from building hosts that can't copy anything but multiples of 8 bytes.
 
Pat LaVarre
 
P.S. Thanks to Robert E for the education re ReadCapacity16 etc.: me, I haven't yet been paying much attention to disk capacities above 2 TiB @ 0.5KiB/block.

	-----Original Message----- 
	From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com] 
	Sent: Mon 9/30/2002 8:27 PM 
	To: t10 at t10.org 
	Cc: 
	Subject: RE: LongLBA bit in READ CAPACITY (10) command
	
	

	* From the T10 Reflector (t10 at t10.org), posted by: 
	* "Elliott, Robert (Server Storage)" <Elliott at hp.com> 
	* 
	Sorry for the delay in responding.  The most recent changes to the READ 
	CAPACITY command are described in T10 proposal 01-246r1, accepted for 
	SBC-2 revision 5.  

	The LONGLBA bit in READ CAPACITY(10) was removed in favor of a READ 
	CAPACITY(16) command.  It used to request the long vs. short format 
	data.  READ CAPACITY(10) now just returns the short format, with a value 
	of FFFFFFFFh if the capacity is too large to express.  If you get 
	FFFFFFFFh, you have to run READ CAPACITY(16) and parse the long format 
	data. 

	The description of LONGLBA was removed but the bit was left in Table 31 
	through SBC-2 revision 7; I will remove it from SBC-2 revision 8 (posted 
	by the November T10 week). 

	--- 
	There are lots of ingredients to the discovery process, some protocol 
	and command set specific. Some things you'll encounter: 
	Protocols: 
	SPI-n: negotiation 
	SPI-3 Ultra 160 SCSI: Domain validation (INQUIRY, READ BUFFER, WRITE 
	BUFFER) to pick correct speed 
	SPI-4 Ultra 320 SCSI: Read INQUIRY to decide to enable information units 
	and QAS 
	Serial Attached SCSI: Program expander routing tables 

	Command sets: 
	Disk drives: Long LBAs, check mode pages 
	Tape drives: implicit vs. explicit LBA modes, ensure mode pages are 
	correct 
	Multimedia: features 

	General: 
	Well-known LUNs (try the REPORT LUNS W-LUN first?) 
	new sense data format 
	persistent reservations (are you always ready for RESERVATION CONFLICT) 
	access controls 
	target port groups 
	determine what optional commands/task management functions are available 
	identify LUs only by their VPD data; support multiple paths 


	I agree that the different (sometimes inexplicably) discovery sequencing 
	across OSes has been a problem, and would welcome an informative annex 
	proposals for SBC-2 that would help this.  SBC-2 would only cover step 3 
	in your list (probing a disk device); finding the LUs themselves is not 
	disk specific (suitable for an annex in SPC-3). 
	-- 
	Rob Elliott, elliott at hp.com 
	Industry Standard Server Storage Advanced Technology 
	Hewlett-Packard

	...

*
* 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 mailing list