bert hubert (ahu@ds9a.nl) writes:
> 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.
Untrue. There are lots of embedded systems where this is not practical.
> > 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.
Won't work for our application. Again, impractical for all but a small
minority of applications.
-
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