Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
mikeblas said:When are sectors not 512 bytes?
Which specific IBM systems do this? Is this extra ECC code available to the application? Since the drive does this in its controller and firmware, they still present only a 512-byte logical sector to the OS.UICompE02 said:There are drives out there that have larger sector sizes which are used for storing ECC code along with the 512 bytes of data. However, these are typically SCSI or Fibre Channel drives and are used only in very specialized situations (IBM has quite a few high-end systems that do something like this). On a typical desktop drive, though, I can't think of a non-512-byte sector setup...
mikeblas said:Which specific IBM systems do this? Is this extra ECC code available to the application? Since the drive does this in its controller and firmware, they still present only a 512-byte logical sector to the OS.
And I thought that all drives use ECC, anyway.
I don't work in a desktop environment. I'll ask our EMC rep about it next time I end up in a meeting with them. I still don't understand why this would be different than the ECC the drive itself calculates.UICompE02 said:Like I said though, you won't likely see a disk like this in a desktop environment.
mikeblas said:I still don't understand why this would be different than the ECC the drive itself calculates.
Each level of the OSI model allows a different payload size. Here, we have only one: 512 bytes. Why should the controller compute the same ECC over the same data that the drive already computed?drizzt81 said:The drive itself, which would be the PHY or DLL, stores its own ECC data on space that is not visible to the outside world. The drive controller (let's say it'd be the equivalent of the IP layer) sends packets that have their own error code, with 512 Bytes data and between 8-16 bytes of ECC.
UICompE02 said:I don't have the model numbers off the top of my head, but mostly AS/400 systems and some fibre channel storage systems provided by EMC and sold by IBM use hard drives with 520, 522, 524, or 528 byte sectors. Like I said though, you won't likely see a disk like this in a desktop environment.
This extra ECC is in addition to the ECC that the drive firmware handles transparently to the OS/application, which all drives use. These extra sectors are available for the hard disk controller in the system and the OS to use for end-to-end error correction.
mikeblas said:Each level of the OSI model allows a different payload size. Here, we have only one: 512 bytes. Why should the controller compute the same ECC over the same data that the drive already computed?
T13 has been looking at this for a while -- have any actually shipped? Did the proposals ever get ratified?Ender said:There are drives out there that employ 1k sector size, and transitioning to 4k sector sizes as well.
Sure. But why compute another one? Why not just make the first accesssible, even if read-only? I can't expect it's that hard, and is less wasteful than computing it and storing it. (And if it is stored as user data, the low-level ECC has to be extended to check and protect the extra ECC. Otherwise, how do you know that the user ECC hasn't been corrupted?)UICompE02 said:Generally, the ECC that the drive automatically calculates and stores (beyond the data sector) is not transmitted across the drive interface, and therefore is not usable to the system. Storing another ECC that is transmitted across the drive interface and stays with the data even when it is placed in the system host memory allows another level of error checking.
BillLeeLee said:16262 * 16 * 63 * 512 bytes/sector = 8 GB
assuming of course, you have 512 bytes/sector.
I was thinking for devices attached via a 'noisy' channel, e.g. an iSCSI device, wouldn't it make sense to add ECC information to the packet that is sent over the network? However, since I have little clue about iSCSI, I am sure that there is some form of error detection anway, which may be independent of the drive's sector size.mikeblas said:Each level of the OSI model allows a different payload size. Here, we have only one: 512 bytes. Why should the controller compute the same ECC over the same data that the drive already computed?
I'd expect there is, but I haven't studied iSCSI much.drizzt81 said:I was thinking for devices attached via a 'noisy' channel, e.g. an iSCSI device, wouldn't it make sense to add ECC information to the packet that is sent over the network? However, since I have little clue about iSCSI, I am sure that there is some form of error detection anway, which may be independent of the drive's sector size.
davidlem said:Your math is correct (or close enough) but you're not going to get the capacity from the info he gave us.
I have 3 old Maxtors in front of me. They all read 16383/16/63 on the label. Their capacities are 10GB, 15GB, 20.4GB. This tells you nothing. Instead, look for the model number (a dead giveaway) OR the LBA count. You can get the model number from the label or your PC's BIOS, if the drive works. The LBA count is often on the label on Maxtors, but not always (more common on the newer ones). Reading LBA is pretty simple - take the digits in the millions place (ie 490 from 490234752) and cut it in half - 245 - this is a 250GB Maxtor.
BillLeeLee said:Yeah, true enough the calculation comes out to ~7.8 GiB (or ~8.4 metric GB), but more interesting question: do you know why all the labels would read the same number of heads, cylinders, and sectors? Surely 3 different drives with 3 very different capacities wouldn't have the same geometry (give equal bytes/sector that is).
UICompE02 said:Here's a link that can explain what's going on:
http://www.boot-us.com/gloss11.htm