Ok, I am a post to the list because I think that's no problem. On Thu, 19 Apr 2007 23:24:23 +0400 Aaron Kulkis <[EMAIL PROTECTED]> wrote:
> eshsf wrote: > > Hello, > > > > On Tue, 17 Apr 2007 22:27:36 -0500 > > "Rajko M." <[EMAIL PROTECTED]> wrote: > > > >> On Tuesday 17 April 2007 04:15, Clayton wrote: > >> ... > >>> I'm assuming the drive is unrecoverable (ie it's not worth risking my > >>> data to try and run the Maxtor tools on it and "repair" the drive)... > >>> so it's up for replacement in the next week or so. > >>> > >> You may try to slow down the drive. > >> I got one that was about to fail, but decreasing the speed, using Maxtor > >> utilities, from 66 to 33 helped and it still runs. > > > > Probably, the decreasing speed problem is because the HDD controller > > changed a bad sector into a spare sector. and the spare sector possibility > > don't optimize to seek, I guess. > > > > AFAIK, A modern HDD has a number of spare sectors. and when happened a bad > > sector, that can replace a bad sector into a spare sector by using the hard > > drive tools, etc. > > *But*, there is a limitation in the number of spare sectors (and depend on > > HDD). > > > > Assuming a 15ms seek time, I sincerely doubt that the original poster > would have noticed the effects of this... that would account for a > whopping 30ms (i.e. 0.03 seconds)...and once the data is read > into memory, it's done ... that disk block is now in the I/O > buffers, and there is no need to revisit it. exactly. when I did post, I didn't consider it at all, almost all the HDD have the I/O buffers on drive and the Linux have a buffer cache though. Yes, so, only when the first accessing it or flushed a cache, it might influence but the influence is a little bit. Thanks, eshsf -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
