On Tue, 11 Apr 2000, bert hubert 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.
Indeed. But disks still fail, always.
> > 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.
I'm just setting up such a box. With two IDE disks, and software RAID-1. I can
remove any disk and it will still boot as if nothing happened. When bad blocks
are detected, the RAID layer kicks the disk/partition in question, and the
system keeps going. I've seen this work in Real Life before. Sure you need to
plan 15 minutes of downtime at some point in the future to replace a failed
disk, but you can actually _plan_ it.
It's often nice to have real spinning disks on such devices (1G of flash isn't
cheap). People need to get over the hardware-raid-or-nothing hump, and realize
that this is indeed a beautiful solution for a large number of problems.
Even if ext2fs (or ext3fs or Reiser or whatever) doesn't address the bad block
problem ideally, we still have viable options. Even on-the-fly bad block
detection and relocation of data cannot save data that's gone.
--
................................................................
: jakob@ostenfeld.dtu.dk : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
-
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