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 passed via the file system to the ATA device. So while the ATA device requires 48 bit ATA addressing, only 32 of those bits can be non zero in this case. This is exactly the same as using a partition that restricts LBAs to 16 bits (e.g. FAT-16) with the original ATA LBA addressing. Although the ATA interface allows the use of 28 bits in the LBA, only 16 could be non zero. Notice that partitions issues are NOT standardized by the ATA standard, but instead are file system unique. ... PS there are actually file systems today that can take full advantage of the 48 bit addressing, since they can have 64 bit LBAs. But they are just now getting into common use (I believe NTFS is one). ... Sent: Tuesday, February 12, 2002 9:50 AM ... I think the current limit is about 2TB given a 512 byte sector. Larger sector sizes would of course push the limit higher. I know that we now commonly see RAID running in the 1TB-10TB range. Depending on the nature of the solution for these boxes, the problem may have already been solved. ... Sent: Tuesday, February 12, 2002 9:11 AM ... I have a forensics-related business and I would like to know if there already is some defined standard about a partition table that handles partition initial LBA address on 48-bit format, since the tradition partition table handles only 32-bit adresses. ATA-6 is already available and I guess that there must be some HDD manufacturer about to lauch some model over 137GB. So, it is a kind of urgent matter. ... Subscribe/Unsubscribe instructions can be found at www.t13.org.
