Cylinders into gigs

R

Ron1jed

Supreme [H]ardness
Joined
Dec 22, 2001
Messages
5,118
I'm a idiot and can't figure it out. I have a maxtor drive. pretty old. 16282 cylinders ,16 heads, 63 sectors. I heard it might be 40 gigs but i really dout that. its a very old drive. any help
 
16262 * 16 * 63 * 512 bytes/sector = 8 GB

assuming of course, you have 512 bytes/sector.
 
mikeblas said:
When are sectors not 512 bytes?
Click to expand...

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...
 
OHhhhh he told you. (does the black thang) ok... but thanks for the info! :D
 
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...
Click to expand...
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.
 
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.
Click to expand...

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.
 
UICompE02 said:
Like I said though, you won't likely see a disk like this in a desktop environment.
Click to expand...
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.
 
mikeblas said:
I still don't understand why this would be different than the ECC the drive itself calculates.
Click to expand...

If I understand UICompE02 it is similar to the way network connections operate with error correction. Each layer uses its own scheme transparently to the layer above: 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.

Then again, if only the controller knows about the extra bytes, I guess it wouldn't matter in terms of calculating the drive size based on the number of cylinders.
 
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.
Click to expand...
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?
 
Also, don't forget possible IOEDC data, in addition to the ECC data. That can be 2+ bytes as well - although to the end user this is treated the same as the regular ECC data.

There are drives out there that employ 1k sector size, and transitioning to 4k sector sizes as well.

/edit:

oh yeah, and back to the original poster's question. the cylinders displayed are not necessarily indicative of the capacity. The actual sector size of today's drives can't really be expressed in logical chs form anymore - there are too many numbers to represent.

If you post what the serial number of the drive is though, I might be able to tell you how big it is.
 
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.
Click to expand...

Yeah I owned a few 2.1gb IBM drives based on a 524 sector size years ago, a low level format put them to a 512 sector size and allowed them to be used in a normal SCSI setup.

They were AS/400 drives, as I recall however I am pretty confident some S390's also used this type of drive in a 520 secotr size config in their storage systems.
 
Not sure if this was mentioned, but you can probably google the serial number and get everything you need, probably also on them maxtor website, that's what I did for 3 maxtor drives that I had no idea what their sizes were.
 
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?
Click to expand...

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. This is known as end-to-end checking. Each interface in between will have its own sort of error checking mechanism as well.

For example, the drive has the previously mentioned on-disk ECC, there is probably some parity signals between the drive and the cache and the cache and the host interface. The host interface (IDE, SATA, SCSI, etc.) will place a CRC or parity on each transmission across the host interface bus. The host adapter controller will probably have parity on its internal buses. The host adapter will be connected by something like PCI that has parity signals or PCI-E that uses a Link Level CRC (or possibly an additional end-to-end CRC on top of this)... Etc, etc.

As you can see, there are many levels of error checking as data is transmitted throughout a computer. The additional End To End CRC is just another level that drives can use, and most host disk controllers will allow any size of sector (though, the greatest portion of the time drives are formatted with 512 byte sectors.)
 
Ender said:
There are drives out there that employ 1k sector size, and transitioning to 4k sector sizes as well.
Click to expand...
T13 has been looking at this for a while -- have any actually shipped? Did the proposals ever get ratified?

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.
Click to expand...
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?)

Parity can be computed with one gate; it's really easy, but it doesn't do correction and just detection. ECC is substantially more complicated to implement.
 
BillLeeLee said:
16262 * 16 * 63 * 512 bytes/sector = 8 GB

assuming of course, you have 512 bytes/sector.
Click to expand...

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.
 
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?
Click to expand...
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.
 
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.
Click to expand...
I'd expect there is, but I haven't studied iSCSI much.

Thing is, unless the same check is used the same way from one place to the other, there isn't "end-to-end checking". The provenance of the check is interrupted once a different -- particularly when a weaker! -- check is used.

I'm burning with curiosity about how this is really implemented, and why it is designed that way.
 
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.
Click to expand...

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).
 
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).
Click to expand...

Here's a link that can explain what's going on:
http://www.boot-us.com/gloss11.htm
 
EMC uses 520 bytes per sector but only 512 is seen by hosts.

They use the extra 8 bytes for checksum an internal checking - basically info used by the array for housekeeping purposes. A sniffer tools slowly scans every sector making sure data is where it is supposed to be,
 
You must log in or register to reply here.
Back
Top