Messages in this thread | | | Date | Sat, 14 Aug 2004 18:23:40 -0600 | From | Andreas Dilger <> | Subject | Re: New concept of ext3 disk checks |
| |
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 a lot of data structures in the kernel, and if any errors are found the superblock is marked with an "error" flag and the next time the system is booted a full fsck is done. The administrator has the option (via the "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 write is that there is a good chance the block is still in cache (either kernel buffer/page cache or disk cache) so this doesn't really add much robustness. The other problem with this is that checking individual block validity doesn't take the "big picture" into account since if we just wrote a block to disk we assume that what we wrote is the correct thing so re-checking this same data doesn't help much.
The periodic fsck of a filesystem snapshot, on the other hand, is as good as you can get for validity checking. The only additional feature needed is online repair, but that is a .00001% requirement vs. actually detecting the error in the first place.
Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
- 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/
| |