thanks, Stephen. these replies are very helpful and will take some time for me to understand... --Tom ----- Original Message ----- From: "Stephen C. Tweedie" <sct@redhat.com> To: "Thomas Bassel" <tbassel@nc.rr.com> Cc: <ext3-users@redhat.com> Sent: Wednesday, May 15, 2002 11:58 AM Subject: Re: when is fsck required? > 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
