In <20000411235646.B8443@home.ds9a.nl> bert hubert (ahu@ds9a.nl) wrote:
> On Tue, Apr 11, 2000 at 04:37:49PM -0500, Ed Carp wrote:
>> The problem with this approach is, if you're working with systems that are
>> up 24x7, to *not* have the ability to automatically detect a bad block,
>> copy the data to another block, then mark that block as bad is a real pain
>> at best and completely unacceptable at worst.
> If you have a bad block on a modern disk it is time for an instant
> backup-and-replace. The concept of a 'bad bit' on a disk is pretty much
> dead.
Yeah, of course. And, since "'bad bit' on a disk is pretty much dead", I must
been thrown that disk with two bad blocks on them two years ago (when that
block was detected first time) even if there are STILL two bad blocks and the
rest works just fine...
>> One of my clients is using Linux in a network communications controller
>> (SONET/ATM backplane) and this sort of thing is going to raise the pain
>> level around here as soon as someone realizes that badblocks aren't taken
>> case of.
> Take out the moving parts and have it do remote logging.
This is nice, of course, but not always feasible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:17 EST