RE: [t13] capacity barriers - 2TiB @ 0.5KiB/block
This message is from the T13 list server. > > Scsi read/write/readCapacity ops > > that can carry more than 32 bits of Lba ... > "Mcgrath, Jim" <[EMAIL PROTECTED]> 02/14/02 07:01PM > the latest draft of > the Block Command Set for SCSI (on www.t10.org) > contains support for 8 byte (64 bit) LBAs. Thanks for the pointer. > The real issue is software implementation, ... > ... And the installed base of software ... ... > > [x88] Read(16) > > [x8A] Write(16) > > [x8E] WriteAndVerify(16) > > [x8F] Verify(16) Looks like t10, as yet, has required devices that need 64 bit Lba's ... ... to learn to move out 16 byte Cdb's. For Atapi as published this means beginning to exercise the long unused SixteenByteCdb option of x0001 = (op xA1 Identify "word" 0 & x0003). For Usb, the long unused option of xC < bCBWCBLength. And so on. > [x2B] SEEK(10) Looks like nobody's bothering to upgrade the Seek command to allow 64 bit Lba's. (Not that I see op x8B in use yet.) > > READ CAPACITY needs more work ... > 5.1.10 [x25] READ CAPACITY command ... > ... [bytes[1] & x02] ... LONGLBA bit ... ... > ... [Editor's note: 01-267 proposes > to eliminate the LONGLBA bit > here in favor of a separate READ CAPACITY (16) command.] Sensible yes, but, like you say, apparently not yet stable. Fun to see Scsi adopting the Ata idea of multiple inequal capacities: given 0.5KiB/block then anything above 2TiB will report both the xFF:FF:FF:FF expressible in four bytes and a larger true maxLba. > (3) If any of [x 0A 2A AA] WRITE (6)/(10)/(12) > is implemented, [x8A] WRITE(16) > shall also be implemented. Somebody's pushing hard. I see the xA8/AA Read12/Write12 forms that raise the maxBlockCount above xFF:FF for maxLba at or below xFF:FF:FF:FF are optional, but the x88/8A Read16/Write16 forms that raise the maxLba above xFF:FF:FF:FF are "mandatory". > Thanks for the pointer. I'm guessing you meant the SBC-2 that includes a dedicatory colour snapshot of Gene Milligan i.e. the last of the trail: http://www.t10.org/ Draft Standards and Technical Reports http://www.t10.org/drafts.htm Command Sets http://www.t10.org/drafts.htm#CMNDSETS SCSI-3 Block Commands (SBC) 1997/11/13, Rev: 08c ftp://ftp.t10.org/t10/drafts/sbc/sbc-r08c.pdf SCSI Block Commands - 2 (SBC-2) ftp://ftp.t10.org/t10/drafts/sbc2/sbc2r04.pdf 2001/07/28, Rev: 04 Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
RE: [t13] capacity barriers - 2TiB @ 0.5KiB/block
This message is from the T13 list server. Please note that both Hale and I specifically requested/adopted the addition of word 103 to the 100-102 original capacity under 48-bit, for the sole purpose of forward thinking to handle 64-bit. So if that is the case where we need to create new commands to handle 64-bit, I am still baffled why we stopped at 48-bit. Yes, Linux does have 64-bit support. --andre On Thu, 14 Feb 2002, Mcgrath, Jim wrote: > This message is from the T13 list server. > > > > Actually the latest draft of the Block Command Set for SCSI (on www.t10.org) > contains support for 8 byte (64 bit) LBAs. The proposals are not final in > this document (for instance, the READ CAPACITY needs more work), although > I'm sure the committee has a better sense of things that may not have yet > been rolled into the document. The real issue is software implementation, > which as we all know can take some time. And the installed base of software > is an even harder problem. > > Linux might be the first widespread operating system to support all of this > - I wonder if anyone is working on it already? > > Jim > > > -Original Message- > From: Pat LaVarre [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 14, 2002 4:53 PM > To: [EMAIL PROTECTED] > Subject: [t13] capacity barriers - 2TiB @ 0.5KiB/block > > > This message is from the T13 list server. > > > > now commonly RAID > > running in the 1TB-10TB range. > > ... the problem may have already been solved. > > Anybody know? > > > > the 32 bit limitation applies to LBA, not just clusters, > > at least at the class driver interface layer? > > Yes 2 TiB will be hitting us real soon now. 1 TiB will hit us before that: > those of us running code on antique (i.e. 32 bit and smaller) processors we > will get to learn who among us forgot that Lba's are unsigned. (Anyone > tried a format utility up there lately?) > > Just as in Ata, raising the max Lba expressible by Scsi has to change in > both directions: read/write commands have to be able to address a large Lba, > and plug 'n play has to be able to persuade the device to disclose that > large Lba's exist. > > The Scsi cdb for op x25 Read Capacity is x 25 0 00:00:00:00 0 00:00 0. All > zeroes except for x25. Magically, "everyone knows" that this cdb really > means move 8 bytes in to the host, of which four bytes are the maxLba (!= > capacity = maxLba + 1) and four bytes are the bytes per block. > > If/when devices want to declare that they contain more than 32 bits of > Lba's, they're going to have to do something New to report capacity. > > Scsi already has longer than normal read/write ops i.e. x A8 AA > Read/Write(12) ... but in their standard form (e.g. Sff 8070i) those only > (uselessly) allow longer counts of blocks/cdb, their Lba fields remain 32 > bits wide. (I hear later Sff8070i made the xA8/AA ops optional.) > > Myself I haven't yet heard of Scsi read/write/readCapacity ops that can > carry more than 32 bits of Lba but maybe http://www.t13.org knows better. > > Pat LaVarre > > > P.S. > > > Larger sector sizes would of course push the limit higher. > > Idema & friends have been speaking of raising the 9 bit limit on > bytes/block. > > For example, variable block lengths: > > > http://www.usenix.org/events/fast/tech.html > > Track-Aligned Extents ... > > And the shorter term future of 4KiB/block: > > > http://www.usenix.org/events/fast/tech.html > > http://www.usenix.org/events/fast/wips.html#mccarthy > > http://www.usenix.org/events/fast/wips/mccarthy.pdf > > Larger Disk Blocks or Not? > Steve McCarthy, Mike Leis, and Steve Byan, Maxtor Corporation > > The recent annual compound growth rate of disk drive areal density has been > 100% - a doubling of capacity every year. This growth rate is faster than > Moore's Law - advances in disk technology have been outpacing advances in > semiconductor technology. Part of the reason for this spectacular growth > rate is that areal density is a two-dimensional problem. Succeeding product > generations increase both the number of tracks per inch (TPI) radially and > the number of linear bits per inch (BPI) circumferentially. However, both > parameters are facing technical challenges that may slow the rate of > capacity growth. In this paper, we will briefly examine some of the > obstacles to increased BPI and propose an increase in sector size as an aid > to surmounting them. > > > >>> 02/13/02 03:36PM > ... > > Note that 2 TB is not too far off. At a doubling of density every year > (which could slow down of course), a single HDD will have this in a bit more > than 3 years. Worse, if you have a RAID with two drives the time is 2 years > off - with 4 drives less than 1 year. > > Considering how long it takes software to be developed and rolled out to the > industry, that's not a very long time. > ... > > So the 32 bit limitation applies to LBA, not just clusters, at least at the > class driver inter
RE: [t13] capacity barriers - 2TiB @ 0.5KiB/block
This message is from the T13 list server. > Linux might be the first widespread operating system to support all of this > - I wonder if anyone is working on it already? Yes. Subscribe/Unsubscribe instructions can be found at www.t13.org.
RE: [t13] capacity barriers - 2TiB @ 0.5KiB/block
This message is from the T13 list server. Actually the latest draft of the Block Command Set for SCSI (on www.t10.org) contains support for 8 byte (64 bit) LBAs. The proposals are not final in this document (for instance, the READ CAPACITY needs more work), although I'm sure the committee has a better sense of things that may not have yet been rolled into the document. The real issue is software implementation, which as we all know can take some time. And the installed base of software is an even harder problem. Linux might be the first widespread operating system to support all of this - I wonder if anyone is working on it already? Jim -Original Message- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 4:53 PM To: [EMAIL PROTECTED] Subject: [t13] capacity barriers - 2TiB @ 0.5KiB/block This message is from the T13 list server. > now commonly RAID > running in the 1TB-10TB range. > ... the problem may have already been solved. Anybody know? > the 32 bit limitation applies to LBA, not just clusters, > at least at the class driver interface layer? Yes 2 TiB will be hitting us real soon now. 1 TiB will hit us before that: those of us running code on antique (i.e. 32 bit and smaller) processors we will get to learn who among us forgot that Lba's are unsigned. (Anyone tried a format utility up there lately?) Just as in Ata, raising the max Lba expressible by Scsi has to change in both directions: read/write commands have to be able to address a large Lba, and plug 'n play has to be able to persuade the device to disclose that large Lba's exist. The Scsi cdb for op x25 Read Capacity is x 25 0 00:00:00:00 0 00:00 0. All zeroes except for x25. Magically, "everyone knows" that this cdb really means move 8 bytes in to the host, of which four bytes are the maxLba (!= capacity = maxLba + 1) and four bytes are the bytes per block. If/when devices want to declare that they contain more than 32 bits of Lba's, they're going to have to do something New to report capacity. Scsi already has longer than normal read/write ops i.e. x A8 AA Read/Write(12) ... but in their standard form (e.g. Sff 8070i) those only (uselessly) allow longer counts of blocks/cdb, their Lba fields remain 32 bits wide. (I hear later Sff8070i made the xA8/AA ops optional.) Myself I haven't yet heard of Scsi read/write/readCapacity ops that can carry more than 32 bits of Lba but maybe http://www.t13.org knows better. Pat LaVarre P.S. > Larger sector sizes would of course push the limit higher. Idema & friends have been speaking of raising the 9 bit limit on bytes/block. For example, variable block lengths: > http://www.usenix.org/events/fast/tech.html > Track-Aligned Extents ... And the shorter term future of 4KiB/block: > http://www.usenix.org/events/fast/tech.html > http://www.usenix.org/events/fast/wips.html#mccarthy > http://www.usenix.org/events/fast/wips/mccarthy.pdf Larger Disk Blocks or Not? Steve McCarthy, Mike Leis, and Steve Byan, Maxtor Corporation The recent annual compound growth rate of disk drive areal density has been 100% - a doubling of capacity every year. This growth rate is faster than Moore's Law - advances in disk technology have been outpacing advances in semiconductor technology. Part of the reason for this spectacular growth rate is that areal density is a two-dimensional problem. Succeeding product generations increase both the number of tracks per inch (TPI) radially and the number of linear bits per inch (BPI) circumferentially. However, both parameters are facing technical challenges that may slow the rate of capacity growth. In this paper, we will briefly examine some of the obstacles to increased BPI and propose an increase in sector size as an aid to surmounting them. >>> 02/13/02 03:36PM ... Note that 2 TB is not too far off. At a doubling of density every year (which could slow down of course), a single HDD will have this in a bit more than 3 years. Worse, if you have a RAID with two drives the time is 2 years off - with 4 drives less than 1 year. Considering how long it takes software to be developed and rolled out to the industry, that's not a very long time. ... So the 32 bit limitation applies to LBA, not just clusters, at least at the class driver interface layer? ... Sent: Wednesday, February 13, 2002 8:02 AM ... NTFS may be able to handle 64-bit LBA's, but the class layer beneath them can only handle 32bit LBA's. The SRB structure defined in the Windows DDK only has a 34-bit LBA field. Microsoft is quite aware of the issue and I believe plans on upgrading to a bigger LBA field in the SRB (or some fix like it) in future OS's. As for time, we have until we get to 2TB to get it worked out. ... Sent: Tuesday, February 12, 2002 11:07 AM ... 48 bit addressing at the ATA level does nothing to affect the way partitions are used. If a partition only allows for 32 bit LBAs (e.g. Fat-32), then only that size LBA can be pa
