Bzzzz wrote: > Bob Proulx wrote: > > > Erasing error output just doesn't erase the cause, > > > and the cause might be very dangerous to the system's > > > health... > > > > Erasing the error output? Why are you erasing error output? I > > never suggested any such thing. > > So you're following attentively the output of the automatic > fsck, excellent...
Sorry. I don't follow your line of discussion.
> > > This also means more frequent FS checks ("I'm waiting
> > > for hours fsck to complete" IS NOT a good excuse).
> >
> > Huh? What? Huh? What are you talking about? I suggested setting
> > FSCKFIX=yes and that most certainly has nothing to do with long
> > fsck check times nor with more frequent checks. Why did you
> > suggest that?
>
> Because some FS errors have an incremental pattern; thus,
> more frequent fsck gives the user a much better chance to
> act before complete brakdown.
I completely agree with this. It is one reason for ext file systems
to implement an fsck check interval after a certain number of months
or a certain number of mounts. By default the check interval time is
usually 6 months. That is only triggered after a subsequent reboot
however. But security upgrades to the kernel usually come through
more often than this so eventually the system will get an fsck check.
A proactive admin should be aware of these things and schedule
appropriate preventative maintenance.
I have mixed feeling about the mount counts interval however. The
mount counts are usually randomized somewhat across multiple file
systems so that they don't all execute at once after a series of
reboots that triggers the check but that only seems partially
effective. It really requires that a system be rebooted regularly and
very often in order for that to be effective. And I don't think just
because a system has been mounted and unmounted perhaps in a very
short period of time (say 30 times in one day) to be an indication of
likely need.
> > > Now, if you think your way's the best, keep on going to the
> > > bottom of it, and just replace fsck with an empty script that
> > > always returns 1.
> >
> > That is a classic "straw man" fallacy.
> >
> > https://en.wikipedia.org/wiki/Straw_man
>
> In the facts, your way is almost the same as avoiding completely
> a fsck (the first reason I gave).
Uhm... No. It isn't. "My way" is setting FSCKFIX=yes. Please read
the documentation for it.
$ man rcS
...
FSCKFIX
When the root and all other file systems are checked, fsck is
invoked with the -a option which means "autorepair". If there
are major inconsistencies then the fsck process will bail out.
The system will print a message asking the administrator to
repair the file system manually and will present a root shell
prompt (actually a sulogin prompt) on the console. Setting this
option to yes causes the fsck commands to be run with the -y
option instead of the -a option. This will tell fsck always to
repair the file systems without asking for permission.
$ man fsck.ext4
...
-a This option does the same thing as the -p option. It is pro-
vided for backwards compatibility only; it is suggested that
people use -p option whenever possible.
...
-p Automatically repair ("preen") the file system. This option
will cause e2fsck to automatically fix any filesystem problems
that can be safely fixed without human intervention. If e2fsck
discovers a problem which may require the system administrator
to take additional corrective action, e2fsck will print a
description of the problem and then exit with the value 4 logi-
cally or'ed into the exit code. (See the EXIT CODE section.)
This option is normally used by the system's boot scripts. It
may not be specified at the same time as the -n or -y options.
...
-y Assume an answer of `yes' to all questions; allows e2fsck to be
used non-interactively. This option may not be specified at the
same time as the -n or -p options.
The default is 'fsck -p' which will bail out and allow the
administrator to manually repair the filesystem.
My previous point was this. Is there anyone reading this mailing list
that would be expert enough in the file system in order to manually
repair it with a file system debugger (it has been ages since I looked
at fsdb for UFS) and to do other than answer yes to any of the
interactive fsck questions?
If the answer is yes then that is awesome! I would love it if they
would write a tutorial for others such as myself to be able to learn
this knowledge and capability. But if everyone is simply going to
answer yes to each interactive fsck questions then they might as well
supply -y on the fsck command line. The result is exactly the same.
> > Somehow you have mutated my suggestion of fixing the problem with
> > ignoring the problem. Ignoring is very, very bad. Why would you
> > even suggest ignoring the problem? I know I didn't suggest
> > ignoring the problem.
>
> But this is what you (1/2) make!
> And don't tell me you're scrutinizing very carefully something
> (the fsck output) you're very used to see, nobody does (nor can).
>
> This is the bottom of the problem: the same as when you find
> the dirty linen in your way in the stairs, you're careful once,
> then you integrate it... until you're wife bawls you out for
> doing so. Except that in this scenario, the HD's full failure
> have 90% chances to be the result.
>
> Hence my proposition to get rid of fsck: you'll save time, never
> your HDz.
I read through this several times. It rather leaves me speechless for
a reply to it. So I will simply note that I read it and move on.
Bob
signature.asc
Description: Digital signature
