On Wed, 02 Apr 2008 18:39:53 +0800, spodosaurus
<spodosaurus@_yahoo_.com> put finger to keyboard and composed:

Well, I did write "AFAICS" which should be taken to mean that
sometimes I can't see very far at all. ;-)

A photo would have been interesting.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

In comp.sys.ibm.pc.hardware.storage Franc Zabkar <fzabkar@iinternode.on.net> wrote:
Matches what I said: There may be errors on the cable, but
they are detected (not: corrected), so the data on disk typically
stays intact. If the disk is detected, then it is detected
correctly. It may, however, fail temporarily or only be
detected in some cases. The OS may also decide the disk is unusable.

Arno

On 2 Apr 2008 00:17:16 GMT, Arno Wagner <me@privacy.net> put finger to
keyboard and composed:

I just tried booting to DOS with Smartdrv disc caching enabled for
drive C:.

If I execute ...

smartudm 0 /r con

.... on my 120GB Seagate HD, the "Seek Error Rate" increases by 8
points each time and the "Raw Read Error Rate" and "Hardware ECC
recovered" values both increase by 3 points. The latter two parameters
have identical values. If your hypothesis were correct, then I would
think that there should be at least as many read errors as seeks.

Instead I suspect that there are no real errors at all. At the very
least it seems to me that all three parameters reflect some kind of
count rather than a rate, although that begs the question, why only 3
reads for every 8 seeks?

To test my hypothesis that the "Seek Error Rate" figure is actually a
count, I captured the SMART data before and after a SeaTools zero fill
operation on a 13GB ST313021A Seagate HD. The difference in the Seek
Error Rate was 52232 counts.

According to the U Series 8 Product Manual ...

http://www.seagate.com/support/disc/.../ata/u8pmb.pdf

.... this drive has 18700 tracks/inch and 3 data surfaces.

Assuming that there are 3 seeks per track (due to the action of the
embedded servo during head switching ???), then one would expect that
the distance between the first and last tracks would be ...

52232 / 18700 / 3 * 2.54 = 2.36 cm

I measured the difference between the outside and inside diameters on
two typical discs to be 3.5cm. Is it plausible that the usable data
area amounts to only 2.36cm of the surface?

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

In comp.sys.ibm.pc.hardware.storage Franc Zabkar <fzabkar@iinternode.on.net> wrote:
You do get the same number of read errors as ECC recoverr, don't you?
That is why the read errors are "raw", they are before attempting ECC.

These are errors, but expected and recoverable ones. Calling
them not real errors is maybe inaccurate, but captures the
spirit. And, yes, these are counts, that get decreased
periodically in some fashion. As to why 3 read errors for 8
seek errors, I would think that not finding a sector is also
a seek error, but if you have nothing, you also have
nothing to read wrongly.

Yes, that requires a seek with modern drives. Historically
head switches could be done without in some designs, and
were faster. Not anymore.

Quite. At least it directly fits what I have seen in 3.5" drives
I opened.

Arno

"Arno Wagner" wrote:

It makes sense that the radius of the outside tracks don't
differ too much from the radius of the inside tracks. Assuming
that all tracks have the same number of bits, the bits on an
outside track that had twice the radius of the inside track would
be twice as long as the bits on the inside track. The ability of
the electronics to interact with the magnetic media is probably
optimized for a small range of bit lengths, and thus for a small
range of track radii.

*TimDaniels*

Timothy Daniels <SpamBucket@NoSpamPlease.biz> wrote
Dud assumption. The datasheets always show that the sectors per
track varys in bands across the platter surface with all modern drives.

See above.

Guess again.

On Fri, 4 Apr 2008 10:25:43 -0700, "Timothy Daniels"
<SpamBucket@NoSpamPlease.biz> put finger to keyboard and composed:

See http://en.wikipedia.org/wiki/Zone_bit_recording

"Zone Bit Recording (ZBR) is used by disk drives to store more sectors
per track on outer tracks than on inner tracks. It is also called Zone
Constant Angular Velocity."

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

On 4 Apr 2008 11:38:50 GMT, Arno Wagner <me@privacy.net> put finger to
keyboard and composed:

What bothers me about the drive's "read error" reporting is that it is
very consistent. I would have thought that reading "preemptively"
before the heads had settled, as you have suggested, would produce
random results. OTOH, it makes sense that a drive manufacturer would
attempt to squeeze more performance out of the drive by doing
something like this.

That makes sense, but only if you accept that *every* seek results in
a seek error. Clearly you would not want the drive to write to the
platter during a seek failure, so the fact that the zero fill
operation completed successfully (Write Error Rate = 0) would suggest
that there were no actual seek errors.

BTW, if you need to be reminded that things are not always what they
seem, then recall the following thread where a Seagate HD appears to
report nonsensical temperature readings. However, the readings make
some kind of sense if one interprets them differently:

http://groups.google.com/group/comp....4?dmode=source

I would think that it would always be faster to read from all heads
simultaneously. However, that would only be possible if you could
guarantee that all heads in the stack were perfectly vertically
aligned at all times, and that there was no temperature gradient.
Clearly that's not the case today.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

"Franc Zabkar" wrote:

Interesting. "CHS" don't mean whut it usetuh.
http://en.wikipedia.org/wiki/Cylinder-head-sector
"CHS values no longer have a direct physical relationship to the data
stored on disks ..." BTW, does "Zabkar" derive from "ZBR"?

*TimDaniels*

"Rod Speed" wrote:
Could you supply a URL or two to these datasheets?

*TimDaniels*

Timothy Daniels <SpamBucket@NoSpamPlease.biz> wrote
http://www.hgst.com/hdd/support/table.htm

"Rod Speed" blurbed:

I meant a URL for the datasheet of an ATA/SATA drive
of speed 7,200rpm and circa 180GB capacity (i.e. not SCSI,
not 15,000rpm, not 1terrabyte capacity), and which says more
than "there are 7 recording zones".

*TimDaniels*

Timothy Daniels <SpamBucket@NoSpamPlease.biz> wrote
Thats all you need, and most datasheets list the
number of sectors per track for the tracks in the zones.

"Rod Speed" wrote:
A URL, please.

*TimDaniels*

Timothy Daniels <SpamBucket@NoSpamPlease.biz> wrote
You got that above.

In comp.sys.ibm.pc.hardware.storage Timothy Daniels <SpamBucket@nospamplease.biz> wrote:

Typically you need a drive manual for that. It seems vendors
have again started to not post these on the web. Datasheets
usually do not give this information.

ZBR has been used for quite some time, I think even my very old
1GB IBM drive had it.

I do like to blow up Rod as much as the next persopn,
but he is right about this. You can see this from HDD speed
benchmarks, e.g., where the speed levels off, while
latency does not (i.e. the rpm, stay the same).
Today you get something like 50%-65% speed at the end of a
disk, compared to the beginning.

An example for 180GB/7200rpm is here:

http://www.hardwarezone.com/articles...94&cid=10&pg=7

I can see about 19 speed zones, and there may be more.

Arno

On 4 Apr 2008 11:38:50 GMT, Arno Wagner <me@privacy.net> put finger to
keyboard and composed:

This is the product manual for the Fujitsu MPG3xxxAT drives:
http://www.fujitsu.com/downloads/AU/...DE_5400RPM.pdf

The specifications on page 19 include the following data:

MPG3153AT MPG3307AT MPG3102/04/09AT
-------------------------------------------------------------
Number of Cylinders 28,928 + 698 30,784 + 769
(User + Alternate & SA)

Track Density 31,000 TPI 33,000 TPI
-------------------------------------------------------------

The usable data area for the MPG3153AT and MPG3307AT models is ...

28928 / 31000 * 2.54 = 2.37 cm

The usable data area for the MPG3102/04/09AT models is ...

30784 / 33000 * 2.54 = 2.37 cm

This compares well with my experimental result of 2.36cm for the
Seagate drive.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

On Sat, 5 Apr 2008 11:19:26 -0700, "Timothy Daniels"
<SpamBucket@NoSpamPlease.biz> put finger to keyboard and composed:

See pages 57 and 58 of this document:
http://www.fujitsu.com/downloads/AU/...DE_5400RPM.pdf

================================================== ================
4.6.4 Time base generator circuit

The drive uses constant density recording to increase total capacity.
This is different from the conventional method of recording data with
a fixed data transfer rate at all data area. In the constant density
recording method, data area is divided into zones by radius and the
data transfer rate is set so that the recording density of the inner
cylinder of each zone is nearly constant. The drive divides data area
into 15 zones to set the data transfer rate. Table 4.1 describes the
data transfer rate and recording density (BPI) of each zone.

MPG3153AT/3307AT

Zone Cylinder Transfer rate [MB/s]

0 0 to 2655 38.59
1 2656 to 5311 38.59
2 5312 to 6527 38.04
3 6528 to 9151 36.71
4 9152 to 11839 35.29
5 11840 to 13823 34.12
6 13824 to 15743 32.94
7 15744 to 18751 30.98
8 18752 to 19583 30.59
9 19584 to 21887 29.02
10 21888 to 24191 27.45
11 24192 to 25631 26.35
12 25632 to 27039 25.29
13 27040 to 28895 23.53
14 28896 to 25927 22.75
================================================== ================

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

On Fri, 4 Apr 2008 19:50:39 -0700, "Timothy Daniels"
<SpamBucket@NoSpamPlease.biz> put finger to keyboard and composed:

IME that's been the case since the early 1990s. The early BIOSes had a
limited drive table with fixed CHS geometries, so until a "user
defined drive type" setting was introduced, HDD manufacturers got
around the problem by using sector translation (and disc drive
overlays if required).

"Zabka" means "little frog", so I guess a "zabkar" is someone who
catches them.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

"Arno Wagner" wrote:
I expected as much. Rod's "help" is usually illusory.

Thanks. That's pretty graphic.

It's also interesting that the legendary "DeathStar" performed so well.
Does it still live up to its nickname since Hitachi took it over?

*TimDaniels*