Hi, On Wed, May 15, 2002 at 11:47:40AM -0400, Thomas Bassel wrote: > by disabling, do you mean deleting fsck from > the install, or not automatically running it after > X months/Y reboots? Never delete fsck, you might need it some day! The best way to disable it, if you want to do that, is to use "tune2fs" to set the fsck-every-N-mounts and fsck-every-N-days counts to zero. That way, fsck will never do a timeout-based fsck, but it will still have a quick look at the filesystem superblock to see if there have been any errors reported on the fs that require a full forced fsck to recover from. > bugs in the ext3 code aside, is there any > advantage in setting it up to autorun at all > or to wait for "something funny to happen"? Only if you are worried about possible hardware corruption. There are just so many ways in which hardware can corrupt data that it's quite reasonable to do a fsck every so often just to be sure, unless you really trust your motherboard, disks and controllers. > what I'm getting at is, if it's allright to not > run fsck for 24 months for ext3, but there's > a chance that a bit flips that goes undetected, > the bit could have flipped during month 1. > if so, users/programs have been using that > bad bit for 23 months. You can't detect that if it happens inside a data file (unless it happens to be inside a file that you can verify independently --- eg. tripwire or rpm can both verify the contents of files recorded in their databases.) The only way to be sure of recovering from that is to take good backups and make archive copies, so if a user does ever spot file corruption, you've got an old copy to fall back to. Cheers, Stephen
