Henrique de Moraes Holschuh wrote:
On Fri, 13 Jun 2008, Johannes Wiedersich wrote:I guess the defaults are very conservative settings regarding reliability of your data and were implemented at a time when there was no journalling for data protection.Actually, kernel bugs, memory problems, corruption in the CPU to disk platter path, and media bitrot are the reasons for which scheduled fsck exist. Journals don't help or hinder it in any way. Otherwise, you'd fsck only on unclean shutdown, or after a known data-trashing event (like an erroneous write access to the raw device, or IO errors on the device, etc).
I'd love an explanation about why only certain filesystem types seem to "need" this fsck as a regular event. Maybe I've got some details wrong, but my understanding has always been that xfs, reiserfs and others don't recommend any "counting" mechanism (to force an fsck at a certain number of boots, or after a certain period of time). If one of you experts has time to enlighten me about this, and whether there's something about the ext2/ext3 family of filesystems that makes it particularly susceptible to corruption, or whether I'm just misinformed about the best practices for these other journaling filesystems (which I admittedly have little 1st-hand experience with), I'd very much appreciate any info or links to info that will teach me more.
thanks so very much in advance, ~c