> > > > Fault tolerance in a filesystem layer means in practical terms
> > > > that you are guessing what a filesystem should look like, for the
> > > > disk doesn't answer that question anymore. IMHO you don't want
> > > > that to be done automagically, for it might go right sometimes,
> > > > but also might trash everything on RW filesystems.
> > >
> > > Let me clarify again: I don't want fancy stuff inside the filesystem that
> > > magically knows something about right-or-wrong. The only _very small_
> > > enhancement I would like to see is: driver tells fs there is an
> > > error while writing a certain block => fs tries writing the same
> > > data onto another block. That's it, no magic, no RAID
> > > stuff. Very simple.
> >
> > That doesn't belong in the filesystem.
> >
> > Imagine you have ten blocks free, and you allocate data to all of them
> > in the filesystem. The write goes to cache, and succeeds.
> >
> > 30 seconds later, the write cache is flushed, and an error is reported
> > back from the device.
>
> And where's the problem?
> Your case:
> Immediate failure. Disk error.
>
> My case:
> Immediate failure. Disk error (no space left for replacement)
>
> There's no difference.
In my case, the machine can continue as normal. The filesystem is
intact, (with no blocks free). The block device driver has to cope
with the error, which could be as simple as holding the data in RAM
until an operator has been paged to replace the disk.
In your case, the filesystem is no longer in a usable state. If that
was the root filesystem, the machine will, at best, probably go in to
single user mode, with a read-only root filesystem.
> Thing is: If there are 11 blocks free and not ten, then you fail
Wrong. See above.
> and I succeed (if there's one bad block). You loose data, I don't.
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:27 EST