drive keeps having partition problems
mechp...@gmail.com
XP Pro machine) that's throwing weird partition issues at the drop of
a hat.
Last week, after the PC crashed in a game, the entire drive (3 primary
NTFS partitions) became inaccessible. Partition Magic 8 showed it as
one errored partition. I could get data off any of the three
partitions with a partition recovery program, but not actually restore
the partitions themselves. I finally had to 0-out the drive and re-
partition.
Now, yesterday, a power surge during a rain storm (he really does know
better than that) it powered down, and when it came back, the first
(active) partition (this time FAT32) was showing as unformatted! (At
least the other 2 partitions are still there and Partition magic can
"see" them.)
All CHKDSK tests, Partition Magic tests, other drive checking programs
all discover no errors with the drive. (Well, once it's partitioned
and formatted).
Any ideas?
Thanks,
Liam
Arno Wagner
Potential reasons:
Driver or hardware issues that cause transient problems and
prevent timely write-back of information (unlikely) or cause
writes to the wring areas. It may be faulty RAM. It may be
a faultu cache entry or the like.
What would be interesting is whether there is any other
data corruption and what its exact form is (e.g.
is there an all-zero sector or is some other data in it).
Have you looked at the SMART attributes (any other test is
really quite meaningless today) and tun a long SMART selftest?
Arno
mechp...@gmail.com
Hmm, how does one look at SMART attributes?
I normally have SMART off at the BIOS (have read SMART can just cause
more issues than it's worth oftentimes.) If I turn it on, what tool
can I use to view the attributes?
I can do another 0'ing out of the drive. Once I do that, how can I
then check to see if indeed it wrote all 0's?
Thanks for the reply!
Liam
Arno Wagner
I use the smartmontools (commandline, available on Linux
and windows). There is also a tool called "Everest", that
allows SMART access. And to just see the attributes, you can
use the current SpeedFan.
> I can do another 0'ing out of the drive. Once I do that, how can I
> then check to see if indeed it wrote all 0's?
Run a long SMART selftest. It does a complete surface scan.
Arno
smlunatick
>
> - Show quoted text -
Head over to Seagate's web site and get the diagnostics for the hard
drive.
http://www.seagate.com/www/en-us/support/downloads/seatools/
Until the drive has been tested and found to be "ok" do not use this
drive at all. It sounds like it is failing.
spodosaurus
Agreed, and for good measure, replace the sata cable. I've just thrown
out yet ANOTHER sata cable that was causing intermittent issues where
the drive would become inaccessible.
Ari
--
spammage trappage: remove the underscores to reply
Many people around the world are waiting for a marrow transplant. Please
volunteer to be a marrow donor and literally save someone's life:
http://www.abmdr.org.au/
http://www.marrow.org/
smlunatick
>
> - Show quoted text -
Drive not accessable is one thing. Erasure of all partition is
another and seems to indicate a big problem since the partitions are
gone but the drive still is connect (BIOS may show it.)
Franc Zabkar
finger to keyboard and composed:
It sounds to me like the FAT32 volume may have suffered some damage to
the FATs or to the boot sector(s). IME CHKDSK has been useless in
repairing these types of problems. Instead I've used Scandisk from
Windows 98SE to repair these faults, although in your case Win98SE
would be limited to 137GB HDs. To see the full 250GB, you would need
to install it in a USB enclosure, or possibly use Win ME's version of
Scandisk.
Whatever you do, do not be tempted to run FIXBOOT on your FAT32 volume
from the recovery console of an XP boot CD. FIXBOOT has a bug that can
fatally damage your filesystem.
Quirks in Scandisk, Chkdsk, Fixmbr, Fixboot:
http://groups.google.com/group/microsoft.public.win98.gen_discussion/browse_thread/thread/b5a85f1e2122af44/88f3f04d4f9e4925?lnk=st&q=#88f3f04d4f9e4925
If you are looking for a DOS based S.M.A.R.T. viewer, then I recommend
SMARTUDM (37KB):
http://www.sysinfolab.com/download.htm
Here is a sample SMARTUDM report for a Seagate HD with 119 reallocated
sectors:
http://www.users.on.net/~fzabkar/SmartUDM/13GB.RPT
Here is a sample Smartctl report:
http://www.users.on.net/~fzabkar/Smartctl/13gb.log
BTW, don't be alarmed by the very high numbers for Raw Read Error
Rate, Seek Error Rate, and Hardware ECC Recovered for Seagate HDs. My
own testing and research leads me to believe that these are normal and
do not in fact reflect errors.
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
mechp...@gmail.com
Easy Recovery Pro found no drive errors, including surface scan, but
it did find partition errors. (And advised to do a drive test. Hrrm.)
The Everest SMART shows OK and "passes" on all lines for the drive.
The smartctl is a bit complicated... I used "-t long" and never got a
report.
But the -H switch indicates overall self-assessment test is PASSED.
Not sure what else I can check.
I'm going to reformat the lost partition and put the OS back on...and
then test again and see if anything changes.
Rod Speed
That doesnt prove anything, post the actual report.
mechp...@gmail.com
Which report?
From smartctl? If so, using what switch? The -H or the -a...?
Franc Zabkar
finger to keyboard and composed:
>Easy Recovery Pro found no drive errors, including surface scan, but
>it did find partition errors. (And advised to do a drive test. Hrrm.)
>The Everest SMART shows OK and "passes" on all lines for the drive.
SMART can pass a disc even if it has hundreds of reallocated sectors.
Such a disc can grow new bad sectors on a regular basis. I took my
13GB Seagate drive out of service after it started doing this.
>The smartctl is a bit complicated... I used "-t long" and never got a
>report.
>But the -H switch indicates overall self-assessment test is PASSED.
>Not sure what else I can check.
>I'm going to reformat the lost partition and put the OS back on...and
>then test again and see if anything changes.
Why don't you take this opportunity to find out exactly which sectors
of the disc have been affected? I'd check the boot sector(s) and FATs.
You can use a sector editor/viewer such as Microsoft's Diskprobe which
is included on your XP CD.
How to Install the Support Tools from the Windows XP CD-ROM:
http://support.microsoft.com/kb/306794/EN-US/
Troubleshooting Disks and File Systems:
http://technet.microsoft.com/en-us/library/bb457122.aspx
Rod Speed
The Everest SMART report. Thats why I put that just under your reference to the Everest SMART report.
> From smartctl? If so, using what switch? The -H or the -a...?
Nope.
Arno Wagner
You don't. You need poll with "smartctl -a <device>". May take
some hours, depending on the drive.
> But the -H switch indicates overall self-assessment test is PASSED.
> Not sure what else I can check.
> I'm going to reformat the lost partition and put the OS back on...and
> then test again and see if anything changes.
The "pass" on the smart attributes are sometimes over-optimistic. Can
you post the output from "smartctrl -a <device>" here?
Arno
Arno Wagner
> On Tue, 1 Apr 2008 08:02:38 -0700 (PDT), mechp...@gmail.com put
> finger to keyboard and composed:
> BTW, don't be alarmed by the very high numbers for Raw Read Error
> Rate, Seek Error Rate, and Hardware ECC Recovered for Seagate HDs. My
> own testing and research leads me to believe that these are normal and
> do not in fact reflect errors.
Same here too. I believe these are from read accesses that were
started immediately after a seek and before the heads really
settled. This is fine, if the read and the ECC fails, the disk can do
a re-read with rettled heads. On writing, the disk gives the
heads more time after a seek.
Arno
spodosaurus
A bad cable can mimic a lot of issues - even causing BIOS to misreport
drive size, yet the drive is still detected, etc.
Franc Zabkar
<spodosaurus@_yahoo_.com> put finger to keyboard and composed:
>A bad cable can mimic a lot of issues - even causing BIOS to misreport
>drive size, yet the drive is still detected, etc.
>
>Ari
I've seen strange BIOS reports for PATA drives.
Here is a case where a dropped bit in a PATA cable caused a FUJITSU
MPE3102AT or MPE3102AP hard drive to be mis-detected by the BIOS as a
"BUJIP5Q IPA3102AP". Consequently a Fujitsu HD diagnostic was unable
to see the drive.
http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/1e561df4ba4b54c4?dmode=source
http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/50a71eb70cc9c35f?dmode=source
AFAICS, a serial (SATA) cable could not produce the same kind of
error. The drive would be either correctly detected or not at all.
Arno Wagner
> <spodosaurus@_yahoo_.com> put finger to keyboard and composed:
>>A bad cable can mimic a lot of issues - even causing BIOS to misreport
>>drive size, yet the drive is still detected, etc.
>>
>>Ari
> I've seen strange BIOS reports for PATA drives.
> Here is a case where a dropped bit in a PATA cable caused a FUJITSU
> MPE3102AT or MPE3102AP hard drive to be mis-detected by the BIOS as a
> "BUJIP5Q IPA3102AP". Consequently a Fujitsu HD diagnostic was unable
> to see the drive.
Fascinating. But I don't see how that would corrupt the partition
table(s). Hmm. Changed bist in sector numbers for writes? But
that should also result in data corruption all over the disk.
> http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/1e561df4ba4b54c4?dmode=source
> http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/50a71eb70cc9c35f?dmode=source
> AFAICS, a serial (SATA) cable could not produce the same kind of
> error. The drive would be either correctly detected or not at all.
It can be detected with error. SATA puts chscksums on all intructions
and data transfers. I had one cable that causet the disk to be
removed from the system (linux) after a few minutes, because there
the kernel got too many disk errors on access.
Arno
spodosaurus
I should have taken a photo last night of the salad like detection of a
WD 320GB SATAII drive that popped onto my screen during drive detection
with a 'bad' cable then :) It on a prior power on it didn't detect the
drive at all on one occasion.
Franc Zabkar
keyboard and composed:
>In comp.sys.ibm.pc.hardware.storage Franc Zabkar <fza...@iinternode.on.net> wrote:
>> On Wed, 02 Apr 2008 11:31:22 +0800, spodosaurus
>> <spodosaurus@_yahoo_.com> put finger to keyboard and composed:
>
>>>A bad cable can mimic a lot of issues - even causing BIOS to misreport
>>>drive size, yet the drive is still detected, etc.
>>>
>>>Ari
>
>> I've seen strange BIOS reports for PATA drives.
>
>> Here is a case where a dropped bit in a PATA cable caused a FUJITSU
>> MPE3102AT or MPE3102AP hard drive to be mis-detected by the BIOS as a
>> "BUJIP5Q IPA3102AP". Consequently a Fujitsu HD diagnostic was unable
>> to see the drive.
>
>Fascinating. But I don't see how that would corrupt the partition
>table(s). Hmm. Changed bist in sector numbers for writes? But
>that should also result in data corruption all over the disk.
Unfortunately the OP in that thread was a technically challenged
elderly gentleman who was too afraid to open up his PC. He expected
all his hardware problems to be rectified from the keyboard. In the
end he frustrated me so much that I kill-filed him. Others persisted
but were unable to extract much useful information from him.
Anyway I believe that instead of "BUJIP5Q" he meant to write "BUJIPSQ"
which would confirm that the fault was confined to a particular bit in
a particular byte in every 16-bit word (the 1st, 5th, 7th, and 9th
bytes were faulty). As the IDE interface is 16-bit, this pointed to a
dropped bit in the cable. In fact I had seen this exact same fault in
a Quantum drive many years before. At that time the solution was to
remove and reseat the IDE cable.
FWIW, here's a personal experience that I found fascinating, but which
I was unable to fully resolve. DOS soundcard software somehow caused a
particular bit to be dropped when accessing the HD.
OPTi 82C931 sound card problems:
http://groups.google.com/group/comp.sys.ibm.pc.soundcard.tech/msg/a484246f62937e44?dmode=source
>> http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/1e561df4ba4b54c4?dmode=source
>> http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/50a71eb70cc9c35f?dmode=source
>
>> AFAICS, a serial (SATA) cable could not produce the same kind of
>> error. The drive would be either correctly detected or not at all.
>
>It can be detected with error. SATA puts chscksums on all intructions
>and data transfers. I had one cable that causet the disk to be
>removed from the system (linux) after a few minutes, because there
>the kernel got too many disk errors on access.
>
>Arno
Then how do you explain spodosaurus's observations?
Franc Zabkar
<spodosaurus@_yahoo_.com> put finger to keyboard and composed:
>Franc Zabkar wrote:
>> AFAICS, a serial (SATA) cable could not produce the same kind of
>> error. The drive would be either correctly detected or not at all.
>
>I should have taken a photo last night of the salad like detection of a
>WD 320GB SATAII drive that popped onto my screen during drive detection
>with a 'bad' cable then :) It on a prior power on it didn't detect the
>drive at all on one occasion.
>
>Ari
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.
Arno Wagner
> On 2 Apr 2008 09:48:17 GMT, Arno Wagner <m...@privacy.net> put finger to
> keyboard and composed:
>>
>>It can be detected with error. SATA puts chscksums on all intructions
>>and data transfers. I had one cable that causet the disk to be
>>removed from the system (linux) after a few minutes, because there
>>the kernel got too many disk errors on access.
>>
>>Arno
> Then how do you explain spodosaurus's observations?
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
Franc Zabkar
keyboard and composed:
>In comp.sys.ibm.pc.hardware.storage Franc Zabkar <fza...@iinternode.on.net> wrote:
>> On Tue, 1 Apr 2008 08:02:38 -0700 (PDT), mechp...@gmail.com put
>> finger to keyboard and composed:
>[...]
>> BTW, don't be alarmed by the very high numbers for Raw Read Error
>> Rate, Seek Error Rate, and Hardware ECC Recovered for Seagate HDs. My
>> own testing and research leads me to believe that these are normal and
>> do not in fact reflect errors.
>
>Same here too. I believe these are from read accesses that were
>started immediately after a seek and before the heads really
>settled. This is fine, if the read and the ECC fails, the disk can do
>a re-read with rettled heads. On writing, the disk gives the
>heads more time after a seek.
>
>Arno
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/manuals/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?
Arno Wagner
> On 2 Apr 2008 00:17:16 GMT, Arno Wagner <m...@privacy.net> put finger to
> keyboard and composed:
>>Same here too. I believe these are from read accesses that were
>>started immediately after a seek and before the heads really
>>settled. This is fine, if the read and the ECC fails, the disk can do
>>a re-read with rettled heads. On writing, the disk gives the
>>heads more time after a seek.
>>
>>Arno
> 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.
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.
> 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?
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.
> 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/manuals/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 ???),
Yes, that requires a seek with modern drives. Historically
head switches could be done without in some designs, and
were faster. Not anymore.
> 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?
Quite. At least it directly fits what I have seen in 3.5" drives
I opened.
Arno
Timothy Daniels
> Franc Zabkar wrote:
>> 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?
>
> Quite. At least it directly fits what I have seen in 3.5" drives
> I opened.
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*
Rod Speed
> Arno Wagner wrote
>> Franc Zabkar wrote
>>> 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?
>> Quite. At least it directly fits what I have seen in 3.5" drives I opened.
> 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,
Dud assumption. The datasheets always show that the sectors per
track varys in bands across the platter surface with all modern drives.
> 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.
See above.
> 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.
Guess again.
Franc Zabkar
<SpamB...@NoSpamPlease.biz> put finger to keyboard and composed:
>Assuming that all tracks have the same number of bits ...
>*TimDaniels*
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
keyboard and composed:
>In comp.sys.ibm.pc.hardware.storage Franc Zabkar <fza...@iinternode.on.net> wrote:
>> On 2 Apr 2008 00:17:16 GMT, Arno Wagner <m...@privacy.net> put finger to
>> keyboard and composed:
>
>>>Same here too. I believe these are from read accesses that were
>>>started immediately after a seek and before the heads really
>>>settled. This is fine, if the read and the ECC fails, the disk can do
>>>a re-read with rettled heads. On writing, the disk gives the
>>>heads more time after a seek.
>>>
>>>Arno
>
>> 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.
>
>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.
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.
>> 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?
>
>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.
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.sys.ibm.pc.hardware.storage/msg/d43ad36cb35d3824?dmode=source
>> 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/manuals/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 ???),
>
>Yes, that requires a seek with modern drives. Historically
>head switches could be done without in some designs, and
>were faster. Not anymore.
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.
Timothy Daniels
> "Timothy Daniels" wrote:
>
>>Assuming that all tracks have the same number of bits ...
>
>
> "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."
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*
Timothy Daniels
> The datasheets always show that the sectors per track
> varys in bands across the platter surface with all modern drives.
Could you supply a URL or two to these datasheets?
*TimDaniels*
Rod Speed
> Rod Speed wrote
http://www.hgst.com/hdd/support/table.htm
Timothy Daniels
> Timothy Daniels wrote
>> Rod Speed wrote
>
>>> The datasheets always show that the sectors per track
>>> varys in bands across the platter surface with all modern drives.
>
>> Could you supply a URL or two to these datasheets?
>
> http://www.hgst.com/hdd/support/table.htm
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*
Rod Speed
> Rod Speed wrote
>> http://www.hgst.com/hdd/support/table.htm
Thats all you need, and most datasheets list the
number of sectors per track for the tracks in the zones.
Timothy Daniels
A URL, please.
*TimDaniels*
Rod Speed
>>>> http://www.hgst.com/hdd/support/table.htm
> A URL, please.
You got that above.
Arno Wagner
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/view.php?id=694&cid=10&pg=7
I can see about 19 speed zones, and there may be more.
Arno
Franc Zabkar
<SpamB...@NoSpamPlease.biz> put finger to keyboard and composed:
>"Franc Zabkar" wrote:
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).
>BTW, does "Zabkar" derive from "ZBR"?
"Zabka" means "little frog", so I guess a "zabkar" is someone who
catches them.
>*TimDaniels*
Franc Zabkar
<SpamB...@NoSpamPlease.biz> put finger to keyboard and composed:
See pages 57 and 58 of this document:
http://www.fujitsu.com/downloads/AU/MPG3xxxAT_IDE_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
keyboard and composed:
This is the product manual for the Fujitsu MPG3xxxAT drives:
http://www.fujitsu.com/downloads/AU/MPG3xxxAT_IDE_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.
Timothy Daniels
> 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.
I expected as much. Rod's "help" is usually illusory.
> An example for 180GB/7200rpm is here:
> http://www.hardwarezone.com/articles/view.php?id=694&cid=10&pg=7
> I can see about 19 speed zones, and there may be more.
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*
Rod Speed
> Arno Wagner 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.
> I expected as much. Rod's "help" is usually illusory.
I just didnt make a distinction between the datasheet and what he calls the manual.
With those Hitachi drives, its the OEM specs that you can see the zone detail listed in.
Folkert Rienstra
Folkert Rienstra
> keyboard and composed:
>
> > In comp.sys.ibm.pc.hardware.storage Franc Zabkar
> > <fza...@iinternode.on.net> wrote:
> > > On 2 Apr 2008 00:17:16 GMT, Arno Wagner <m...@privacy.net> put finger to
> > > keyboard and composed:
> >
> > > > Same here too. I believe these are from read accesses that were
> > > > started immediately after a seek and before the heads really
> > > > settled. This is fine, if the read and the ECC fails, the disk can do
> > > > a re-read with rettled heads. On writing, the disk gives the
> > > > heads more time after a seek.
> > > >
> > > > Arno
> >
> > > 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.
> >
> > 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.
> What bothers me ...
... is that you take that idiot seriously ...
> 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.
No. Really?
> OTOH, it makes sense that a drive manufacturer would
> attempt to squeeze more performance out of the drive by doing
> something like this.
>
> > > 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?
> >
> > 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.
> That makes sense, but only if you accept that *every* seek results in
> a seek error.
So it does *not* make sense.
> 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:
Which is why they are called mfgr dependent.
>
> http://groups.google.com/group/comp.sys.ibm.pc.hardware.storage/msg/d43ad36cb35d3824?dmode=source
>
> > > 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/manuals/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 ???),
> >
> > Yes, that requires a seek with modern drives. Historically
> > head switches could be done without in some designs, and
> > were faster. Not anymore.
> 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.
Nor was it ever, except for one or two experiments.
Folkert Rienstra
Folkert Rienstra
> > "Timothy Daniels" wrote:
> >
> > > Assuming that all tracks have the same number of bits ...
> >
> > 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."
>
>
> Interesting. "CHS" don't mean whut it usetuh.
And you give the word Newbee a whole new meaning.
How long have you been here? And not learned a single bit, ever.
Folkert Rienstra
> > On Tue, 1 Apr 2008 08:02:38 -0700 (PDT), mechp...@gmail.com put
> > finger to keyboard and composed:
> > BTW, don't be alarmed by the very high numbers for Raw Read Error
> > Rate, Seek Error Rate, and Hardware ECC Recovered for Seagate HDs. My
> > own testing and research leads me to believe that these are normal and
> > do not in fact reflect errors.
> Same here too. I believe these are from read accesses that were
> started immediately after a seek
Like there is any other way.
> and before the heads really settled.
The heads are assumed settled once the sector mark (in the servo data)
has been recognized (it bloody well has to since the servo data is read by
the same head) and the synchronization field field has passed the head.
Obviously you can't read the datafield *before* it passes the head.
> This is fine, if the read and the ECC fails, the disk can do
> a re-read with rettled heads.
Pity that to be able to read the sector contents the sector marks have to
be read first. If the drive would still have trouble to read the sector da-
ta already, imagine how it would be even worse reading the sector marks,
before that.
> On writing, the disk gives the heads more time after a seek.
Pity that the distance of the sector marks and the data field is the same for
reading and writing. Once the sector mark is read, the data field follows
in a fixed time. No waiting whatsoever. If not, the drive has a full rotation
time before it can try again.
>
> Arno
Folkert Rienstra
> <SpamB...@NoSpamPlease.biz> put finger to keyboard and composed:
>
> > "Franc Zabkar" wrote:
> > > "Timothy Daniels" wrote:
> > >
> > > > Assuming that all tracks have the same number of bits ...
> > >
> > > 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."
> >
> >
> > 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 ..."
>
> 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).
Bullshit.
Yousuf Khan
>> Have you looked at the SMART attributes (any other test is
>> really quite meaningless today) and tun a long SMART selftest?
>>
>> Arno
>
> Hmm, how does one look at SMART attributes?
> I normally have SMART off at the BIOS (have read SMART can just cause
> more issues than it's worth oftentimes.) If I turn it on, what tool
> can I use to view the attributes?
I keep the SMART warnings turned on in BIOS always. The only "more
issues than it's worth"-type problems are merely inconvenience issues.
For example, if SMART does detect an error on a drive, BIOS will throw
up the warning during boot time, and then stop the boot process until
you read the message and manually tell it to continue. This will happen
everytime you boot, and if you're rebooting often (eg. during Windows
patch updates), this can become annoying.
However, SMART is one of the most lenient error detection schemes out
there. It usually finds no errors, so if it actually finds something
then it's usually a sign that the drive truly needs to be replaced
sooner rather than later.
Yousuf Khan
Folkert Rienstra
> mechp...@gmail.com wrote:
> > > [Babbleshit snipped]
> > >
> > > Arno
> >
> > Hmm, how does one look at SMART attributes?
> > I normally have SMART off at the BIOS (have read SMART can just
> > cause more issues than it's worth oftentimes.) If I turn it on, what tool
> > can I use to view the attributes?
>
>
> I keep the SMART warnings turned on in BIOS always. The only "more
> issues than it's worth"-type problems are merely inconvenience issues.
> For example, if SMART does detect an error on a drive, BIOS will throw
> up the warning during boot time, and then stop the boot process until
> you read the message and manually tell it to continue. This will happen
> everytime you boot, and if you're rebooting often (eg. during Windows
> patch updates), this can become annoying.
> However, SMART is one of the most lenient error detection schemes out
> there. It usually finds no errors, so if it actually finds something
> then it's usually a sign that the drive truly needs to be replaced
> sooner rather than later.
Nonsense again.
S.M.A.R.T. doesn't differentiate between internal and external induced errors.
If the PS is at fault replacing the drive won't help.
>
> Yousuf Khan
Rod Speed
He used the word USUALLY for a reason, fool.
Folkert Rienstra
Rod Speed
Never ever could bullshit its way out of a wet paper bag, fuckwit.
Yousuf Khan
> Nonsense again.
> S.M.A.R.T. doesn't differentiate between internal and external induced errors.
> If the PS is at fault replacing the drive won't help.
Hello precious, your momma been spanking you again? Dry your tears and
go tell her you're a person and you deserve to be respected. :)
Yousuf Khan
Rod Speed
> Folkert Rienstra wrote
>> Nonsense again.
>> S.M.A.R.T. doesn't differentiate between internal and external
>> induced errors. If the PS is at fault replacing the drive won't help.
>
>
> Hello precious, your momma been spanking you again?
Nar, its those nice fellas in white coats that are his problem.
> Dry your tears and go tell her you're a person and you deserve to be respected. :)
No one respects rabid loonys except that they dont bother with those funky canvas jackets
with extremely long sleeves anymore, just taser them and inject them to keep them under control.
Squeeze
And another troll that drops the mask.
Trolls aren't what they used to be, these days.
They're so easily provoked. It's so disappointing.
Squeeze
I'll bet that you know all this from personal experience, yes?
Dave Seven
> However, SMART is one of the most lenient error detection schemes out
> there. It usually finds no errors, so if it actually finds something
> then it's usually a sign that the drive truly needs to be replaced
> sooner rather than later.
>
> Yousuf Khan
But you can just run HDtune (free version) and it will read the SMART
info without having to have it enabled in the bios.
Dave Seven
> Never ever could bullshit its way out of a wet paper bag, fuckwit.
>
>
Isn't that the exact same flame you have been using for the past ten
years? Time to buy the new 'Flaming For Dummies' book as they have now
expanded it beyond one flame.
Dave Seven
> No one respects rabid loonys
And you should know that better than anyone here.
Franc Zabkar
put finger to keyboard and composed:
>Yousuf Khan wrote:
The following article suggests that S.M.A.R.T is always enabled as far
as the drive is concerned. The BIOS setting merely controls whether
the BIOS will test the SMART health status of a disc at bootup.
http://smartmontools.sourceforge.net/
=====================================================================
My computer's BIOS has a SMART enable/disable setting. What does it
do, and how should I set it?
Some type of BIOS can check the SMART health status of a disk at
bootup ... This one-time check on bootup is done if the BIOS SMART
setting is set to 'ENABLE', and is not done if the setting is set to
'DISABLE'.
If this one-time check is done, and the disk's health status is found
to be 'FAIL', then typically the BIOS will display an error message
and refuse to boot the machine.
For the proper functioning of smartmontools [or any other SMART
software tool], either BIOS setting may be used.
=====================================================================
Squeeze
> put finger to keyboard and composed:
>
> > Yousuf Khan wrote:
> >
> > > However, SMART is one of the most lenient error detection schemes out
> > > there. It usually finds no errors, so if it actually finds something
> > > then it's usually a sign that the drive truly needs to be replaced
> > > sooner rather than later.
> > >
> > > Yousuf Khan
> >
> > But you can just run HDtune (free version) and it will read the SMART
> > info without having to have it enabled in the bios.
> >
> >
> > http://www.hdtune.com/
> The following article suggests that S.M.A.R.T is always enabled as far
> as the drive is concerned.
Silly you:
Page 247
8.51.1 SMART DISABLE OPERATIONS
8.51.1.1 Command code
B0h with a Feature register value of D9h.
8.51.1.2 Feature set
SMART feature set.
- Mandatory when the SMART feature set is implemented.
- Use prohibited when the PACKET Command feature set is implemented.
8.51.1.8 Description
This command disables all SMART capabilities within the device including any and all timer and event count
functions related exclusively to this feature. After command acceptance the device shall disable all SMART
operations. SMART data shall no longer be monitored or saved by the device. The state of SMART, either
enabled or disabled, shall be preserved by the device across power cycles.
T13 Draft 1410D
Franc Zabkar
That depends on the BIOS.
The SMART enable/disable setting in the AMI BIOS of my PCChips socket
7 M571 mainboard has no effect on SMART reporting. When I run the
Smartudm utility after a DOS boot, it always shows that SMART is
enabled, and the SMART attributes are always updated.
OTOH, the SMART enable/disable setting in my ECS L7S7A2 AMI BIOS does
disable the updating of SMART attributes. Smartudm shows it as
disabled on its first run. Subsequent passes show it as enabled (by
Smartudm), until the next reboot when the BIOS reverts it to disabled.
>> The BIOS setting merely controls whether
>> the BIOS will test the SMART health status of a disc at bootup.
>>
>> http://smartmontools.sourceforge.net/
>>
>> =====================================================================
>> My computer's BIOS has a SMART enable/disable setting. What does it
>> do, and how should I set it?
>>
>> Some type of BIOS can check the SMART health status of a disk at
>> bootup ... This one-time check on bootup is done if the BIOS SMART
>> setting is set to 'ENABLE', and is not done if the setting is set to
>> 'DISABLE'.
>>
>> If this one-time check is done, and the disk's health status is found
>> to be 'FAIL', then typically the BIOS will display an error message
>> and refuse to boot the machine.
>>
>> For the proper functioning of smartmontools [or any other SMART
>> software tool], either BIOS setting may be used.
>> =====================================================================
>>
>> - Franc Zabkar
Squeeze
Pity about the "S.M.A.R.T is *always* enabled as far as the drive is concerned".
>
> The SMART enable/disable setting in the AMI BIOS of my PCChips socket
> 7 M571 mainboard has no effect on SMART reporting. When I run the
> Smartudm utility after a DOS boot, it always shows that SMART is
> enabled, and the SMART attributes are always updated.
>
> OTOH, the SMART enable/disable setting in my ECS L7S7A2 AMI BIOS
> does disable the updating of SMART attributes. Smartudm shows it as
> disabled on its first run. Subsequent passes show it as enabled (by
> Smartudm), until the next reboot when the BIOS reverts it to disabled.
Right, S.M.A.R.T is *not* always enabled as far as the drive is concerned.
[snip]
Franc Zabkar
put finger to keyboard and composed:
>Franc Zabkar wrote in news:m7ta14lsrs1ql5uka...@4ax.com
>> The SMART enable/disable setting in the AMI BIOS of my PCChips socket
>> 7 M571 mainboard has no effect on SMART reporting. When I run the
>> Smartudm utility after a DOS boot, it always shows that SMART is
>> enabled, and the SMART attributes are always updated.
>>
>> OTOH, the SMART enable/disable setting in my ECS L7S7A2 AMI BIOS
>> does disable the updating of SMART attributes. Smartudm shows it as
>> disabled on its first run. Subsequent passes show it as enabled (by
>> Smartudm), until the next reboot when the BIOS reverts it to disabled.
>
>Right, S.M.A.R.T is *not* always enabled as far as the drive is concerned.
The author of smartmontools is both right and wrong depending on which
version of BIOS you have.
Squeeze
Pity that the author of smartmontools didn't say anything of the sort.
The conclusion was all your's and no one elses.
>
> - Franc Zabkar