Re: New concept of ext3 disk checks

From: Otto Wyss
Date: Sat Aug 14 2004 - 02:18:16 EST


On Aug 12, 2004 18:39 -0400, Theodore Ts'o wrote:
> > - Instead of checks forced during startup checks are done during runtime
> > (at low priority). It has to be determined if these checks are _only_
> > checks or if they also include possible fixes. Possible solution might
> > distinct between the severity of any discovered problem.
>
> This is something that doesn't require any kernel patches, or any
> other C coding for that matter, so it would be a great first project
> for someone who wanted to learn how to use the device-mapper snapshot
> feature. Basically, what you do is the following in a shell script
> which is fired off by cron once a week at 3am (or some other
> appropriate time):

Instead of a daily cron job I envision a solution where writes to the
disk are checked for correctness within a short time lag after they have
been done. Assume this time lag is set to a few minutes, on a high
performance system not each write of a certain node gets checked while
on a desktop system most probably each single write is. Choosing the
right time lag gives a balance of discovering problems fast against
additional disk access.

Okay, such tests could be done by a constantly running background task
in user space. But since journalling just should guarantee that any disk
access is done correct, even in case of problems, it should be
considered if such test can be integrated there. This has the advantage
that if journalling is able to guarantee correctness by other means
these test aren't needed at all and may be completely remove.

What I want to achieve with this new concept is that the file system
itself not only tries to prevent any data corruption but also tries to
detect and report it if corruption still has happened anyway.

O. Wyss

--
See a huge pile of work at "http://wyodesktop.sourceforge.net/";
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/