On Aug 14, 2004 09:15 +0200, Otto Wyss wrote:> 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.

The ext3 (and ext2) kernel code already does consistency checking of alot of data structures in the kernel, and if any errors are found thesuperblock is marked with an "error" flag and the next time the systemis booted a full fsck is done. The administrator has the option (viathe "errors=" mount option) to either panic the kernel, remount read-only,or continue using the filesystem if an error is found.

The problem with re-reading blocks and checking for validity after a writeis that there is a good chance the block is still in cache (either kernelbuffer/page cache or disk cache) so this doesn't really add much robustness.The other problem with this is that checking individual block validitydoesn't take the "big picture" into account since if we just wrote a blockto disk we assume that what we wrote is the correct thing so re-checkingthis same data doesn't help much.