>
> 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?
>
However many times the system encounters a bad block it may very well
not be in use or it is about to be updated so its contents are unimportant.
I would suggest when a block is found to be bad during a write operation the
block should be marked as bad and the write operation retried (now on a
different block of course since the bad one was marked bad). DOS was able
to do this with the verify option on. It would also be nice if there was
something similar in a read operation perhaps retrying the read operation a
certain number of times to see if it can successfully retreive the
information and move it to a good block before giving up and bombing out.
By the way a verify writes feature would be very useful especially on a
floppy. I've noticed its quite common to not get any error during a write
operation on a floppy only to be burned (moments) later when trying to read
the information back from the floppy and having it fail. I never
encountered a similar problem in DOS when using its verify writes option.
> 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.
>
-
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