On Thu, Jul 19, 2012 at 06:44:44PM +0200, David Sommerseth wrote:
> > 
> > tune2fs -c 0 -i 0 /dev/....
> 
> If using ext{2,3,4}, I would strongly recommend *against* doing this.
>


It depends on your environement. Scheduled runs of fsck is good.

Unscheduled unplanned runs of fsck that also detect corruption that
cannot be automatically repaired and require expert intervention
is usually bad.

Here, for us, when we run an experiment, if the DAQ computer has an unscheduled reboot
(user bumped the power switch and similar) it is not desirable to have the experiment
stop taking data (TRIUMF proton beam is not very cheap in $$$/hour) just because
RHEL/SL decides that that is the perfectly great time to run fsck, detects some trivial
corruption and sits there waiting for an expert to type in the root password
and the special fsck incantation. And if this happens on Sunday night, the expert is not
coming in until Monday morning (count the beam hours lost, multiply by beam cost
per hour, add lost man-hours of experimenters sitting idle, etc).


>
> Running fsck from time to time isn't a bad thing.
>

Running fsck requires a scheduled outage of unpredictable duration (if fsck finds problems).

I think fsck should be able to run in the background all the time.

I am sure the ext2/3/4 filesystem driver and fsck can be made to talk to each other
and permit checking a mounted live filesystem. (SUN ZFS can do this).


> For reiserfs it is not needed, it will take care of this
> on its own - and really needed, ...


History lesson. When the SGI XFS filesystem first came out, it did not have
an xfsrepair tool. The promotional literature promised a "corruption-proof" filesystem.
Guess what came in with the next system update (yes, the xfsrepair program).


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada