Ed Carp writes:
> 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.
The real issue is that by the time you get a block error at the filesystem,
it is often too late to fix the contents, so even if you _could_ do anything
about it, what would you do? Copy potentially bad data to a new block? Put
an emtpy block into a file and watch your application crash?
What you really want is mirroring below the filesystem (or RAID) to handle
bad blocks, so that the filesystem never sees them. No sense in putting
bad block correction into every filesystem, since you can do it once
correctly for all filesystems, as well as raw devices via MD. Even better
would be if LVM could do mirroring, so you could do mirroring and relocation
at the PP/PE level instead of a whole partition at a time.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
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