Messages in this thread |  | | | Date | Fri, 28 Aug 1998 16:56:32 +0200 (CEST) | | From | tl <> | | Subject | Re: sector size of 2068? |
| |
On Thu, 27 Aug 1998, Richard B. Johnson wrote: > On Thu, 27 Aug 1998, Brandon S. Allbery KF8NH wrote: > [SNIPPED] > > | optimization to select the proper head, etc. Therefore I doubt > > | that the "real" block-size is 2068. In practice, it's usually > > | 512 or a multiple thereof. > > +--->8 > > > > It has been suggested that they chose a format that makes the disk look as > > big as possible. That it's not *usable* in that format (to my knowledge, no > > other OS does 2068-byte sectors either) isn't significant to marketroids > > pushed to "demonstrate" their numbers.... > > > > It's unlikely that the report from SCSI `read capacity` command is > correct. The firmware in most drives that I've seen maintain a > "bitmap" that tells the hardware what head to use. Essentially > when you run out of the bits representing a read or write in progress, > you automatically pick up the next head via a simple hardware decode. > > This won't work with sector lengths that are not powers-of-two.
Many high-end SCSI disks aimed for servers DO support non-power of two sectors. I have 5 Seagate Cheetah 9 formatted at 528 bytes sectors for example... (By a DPT controller, to support error correction over the SCSI bus & cache!)
A quick check of the online datasheets tends to support this, IBM Ultrastar 2XP/9LP/9ZX/18XP models support this. Seagate's online datasheets doesn't say it specifically, but they DO tell us that many of the values are only valid for 512 byte sectors, and more detailed datasheets confirms this for at least the Barracuda and Cheetah's. Quantum Atlas *appears* to not support it (some older Quantums had support for it thought).
Seagate doesn't give the sector-size limits for their disks on the online datasheet, but IBM does, and their drives support either 512-732 or 512-740 bytes sector sizes (different models).
> Spiral disks (for video, etc.) make extensive use of bitmap control. > > So I think that the 2068 really means "this drive has not been formatted".
It's a *LOT* more likely that it's formatted for 2048 bytes sectors, plus 20 byte of extra error correction.
Using slightly larger sector seems to be a somewhat common usage in hot-pluggable RAID systems, since you can expect certain amount of noise on the SCSI bus when a disk is unplugged/replugged...
The DPT SmartRaid IV controllers (PM3334 series) uses either 512 byte or 528 byte sectors, the 528 byte sector format isn't supported on all disks thought, and you also need to have DPT's memory chips instead of standard RAM for the cache.
(DPT has a list of certified disks, and if your disk isn't there, but the 528-byte sector option is available you are recommended to run drive diagnostics afterwards if you decide to use 528-byte sectors. The list I have is more than a year old and contain mostly Seagate Barracuda's and Fujitsu's and one Quantum and one Micropolis).
Now, using 528 bytes sector does give slightly smaller usable drive-space (about 3%). If you instead use 2068/2048 byte sectors you would probably get at *least* the rated size, possibly even a little more, with approximately similar failure detection capabilities.
This might make 2068 byte sectors rather interresting for a hardware RAID vendor that provides hot-plug support, especially since it could easily hide the non-standard sector sizes and report normal 512-byte sectors to the host OS...
Interrestingly enough the drive in question with 2068 byte sectors was a Seagate Elite 9, and the online specification for the Elite 23 (it's closest relative that's still available) doesn't note any sector size limits at all, but does note that both the formatted size and the number of sectors given are only valid for 512 byte sectors.
Just as on the Barracuda and Cheetah's online specifications, both which are well-know to support at least SOME non-power of 2 sector-sizes...
> Your point about disk size is noted. It would be nice to find out if > the drive really has its stated capacity (after it is formatted). I > think you will be pleasantly surprised. Most SCSI drives have LOTS > of spare sectors which are marked spare so the drive capacity is > artificially reduced to the published capacity during the format. > > Bad sectors are transparently re-mapped during use so SCSI drives > should never have any "bad sectors". If they occur, it's time to > back up everything and low-level format it again.
Usually they are only transparently remapped when the failure is recoverable, aka soft errors (aren't there a mode-page bit to change this?). Some also remap when they *overwrite* a failed sector.
But it shouldn't silently reassign sectors with hard errors, since that would lead to data-loss. AFAIK some do the reassign on overwrite by reassigning directly, but still reporting it as failed (by setting some internal bit) until it's overwritten.
I've heard claims that some drives drops their grown defect list when they do a low-level format, in which case a low-level format would not be a really good thing to do if you have problems with bad sectors... Except if you did thorough destructive read/write tests afterwards, but then it would probably be better with just the same destructive tests.
The one case I can think of where a low-leve format would be significantly better than a thorough test would be when the grown defect list is getting full, but then the disk is essentially dead anyway, it'll probably find the same defects again pretty soon.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
|  |