Don Quixote de la Mancha wrote:
> All of the hard drive vendors provide disk drive diagnostic tools,
> that are able to access vendor-specific - and undocumented - firmware
> in their drives. This diagnostic firmware is able to diagnose drive
> hardware problems in a much more thorough way than the vendor-neutral
> S.M.A.R.T. is able to.
>
> These utilities are always provided in the form of DOS boot disk
> images; one generally has a choice of making a floppy or a CD-ROM.
I downloaded said software, and burnt a CD-ROM. I ran the diagnostics
on both discs (both are WDs, but of different sizes). The smaller
one passed both a "quick" test, and an "extended" full surface scan
test, and both in about the amount of time the tool estimated. The
larger one (the one I'm having performance problems with) failed the
"quick" test, due to timeout, after several times the estimated
run time, but passed the "extended" full surface scan, though it took
significantly longer than estimated. The estimated time was just over
15 hours, but the test ran 83 hours 33 minutes.
> Finally they all have a destructive test, in which the diagnostic
> writes zeroes to every sector of the drive.
I did not try to run the destructive tests. There is one which performs
a write test, and another which is not a test, but just intended to
write zeros to all sectors.
> No matter what, if you think one of your drives might be flaky, back
> them both up at once, before doing anything else.
That goes without saying.
> Being fully backed up also gives you the advantage that you can then
> run the destructive sector-zeroing test. I feel it's a good thing to
> do in any case, just to "exercise the bits".
I'm not prepared to run another 83 hours non stop off line.
[...]
> Hope That Help,
Well, so far what the software has told me is that the disc appears
to be OK, but very slow, which is what I already knew.
I want some help getting information out of the kernel to see what
it thinks. Anyone familiar with how to do that?
I've wondered whether DMA might be disabled, or perhaps it's not
running with interrupts, but hdparm seems to think that both drives
are essentially running the same...
(ok drive)
# hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 78165360, start = 0
(slow drive)
# hdparm /dev/hdb
/dev/hdb:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 38913/255/63, sectors = 625142448, start = 0
It's odd that hdparm is unable to notice that the disc is slow.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
