On Friday 19 February 2010 13:50:59 Mike McCarty wrote: > 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. what does hdparm -tT /dev/hdb show? Dave > > Mike > -- 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
