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