[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: when is fsck required?



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]