This message is from the T13 list server.
[EMAIL PROTECTED] wrote:
This message is from the T13 list server. Please look at this new doc that Dan posted yesterday, for the April meeting. e05120r0 - Alignment of logical sectors within a long physical sectorhttp://t13.org/docs2005/e05120r0-ACS-logical_sector_alignment.pdf
Hmmm... I'm curious how this got all messed up?!
I made the original proposal for supporting a larger physical sector size based on these points:
1) Since it was unlikely that the ATA transport protocols would be changed to support data transfers that were something other than N*512 bytes and that changing to the logical sector size would break virtually all software that used ATA disk drives, a logical sector on an ATA device would remain 512 bytes and each logical sector would have a unique logical block address starting at LBA 0 and incrementing by one for each logical sector.
2) It would be transparent to the host that used 512 byte logical sectors that the drive was using a physical sector size that is a multiple of 512 bytes. How a device stored the logical sectors in or on its media was device specific. HOWEVER, how the drive transferred logical sectors to the host WAS NOT drive specific. Continue reading...
3) If some day in the future the ATA protocols were changed and new commands existed to support native data transfers of a sector size that was not 512 (but still N* 512) bytes, then a host should be able to mix the old traditional commands with the new commands without a data integrity problem. This requires that the drive and host have the same understanding of the layout of logical sectors. That layout is shown below. It is very important to understand this has nothing to do with how the data is physically stored by the device - it only specifies how the host and drive access the data in a consistent manner.
4) A host that wants to use a larger logical sector size needs to restrict the LBA values it uses in a R/W command so that those LBAs are on a proper boundary for the larger logical sector size. However, assuming the host is using a R/W command that has a larger logical sector size (such a command does not exist today) there shall be no data integrity problem if the host fails to do this - the device shall either reject the command or perform the correct data transfer (with a performance penalty?).
Now the examples...
Assume a drive keeps 8 logial sector per physical sector. Again, how the device stores this data on or in its media is device specific.
For a tradition host or a host using traditional R/W commands that transfer N*512 bytes the host can start a transfer at any LBA with any sector count:
<LBA 0><LBA 1><LBA 2><LBA 3><LBA 4><LBA 5><LBA 6><LBA 7>
For a host that would like to use 1024 byte sectors then that host would use a new command (that does not exist today) and never set bit 0 of an LBA to a non-zero value. A R/W of LBA 0 would transfer the data in LBA 0 and then LBA 1:
<LBA 0><LBA 1><LBA 2><LBA 3><LBA 4><LBA 5><LBA 6><LBA 7> <---LBA 0---><---LBA 2---><---LBA 4---><---LBA 6--->
For a host that would like to use 2048 byte sectors then that host would use a new command (that does not exist today) and never set bits 0 and 1 of an LBA to a non-zero value. A R/W of LBA 0 would transfer LBA0, then LBA1, then LBA2 and then LBA3:
<LBA 0><LBA 1><LBA 2><LBA 3><LBA 4><LBA 5><LBA 6><LBA 7> <----------LBA 0----------><--------LBA 4------------>
And so forth.
Now what is the problem?
Is someone trying to demand that a device implement only one way that the data is "physically stored"? Why does that matter? A consistent view of the way LBA values are related is all that is required to maintain data integrity.
Is someone trying to prevent me from implementing a device that has appears to have large "physical sectors" but doesn't store the logical sectors in the same order as shown above? What purpose does that serve?
--
++ Hale Landis ++ www.ata-atapi.com ++
