Re: [PATCH] e2fsck: Do not to be quiet if verbose option used.

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Apr 29, 2019 at 07:16:36AM +0300, Alexey Lyashkov wrote:
> Theodore,
> 
> Usecase is simple. User use a -p with -v flag,
> in this case, -p block any messages on console in case it successfully fixed.
> It’s OK _without_ -v flag, situation is different with -v flag.
> In this case, user expect to see mode debug info about check/fix process,
> and «no messages» in this mode confuse a user, as he think «no messages» == «no bugs fixed»,
> but it’s not a true in common way.
> From other side, -p print a messages about fix process, but not for bitmaps, it’s source of additional
>  confuse for the user, as he lack an info about FS changes during e2fsck run.

That's not a use case.   *Why* is the user using -p?

The -p option is only intended to be used when called from boot
scripts, where e2fsck is run in parallel.  This usage, "preen mode"
dates back to BSD 4.3.  What it does is pretty clearly described in
the man page.

The user seems to be very confused with their expectation, and it's
not at all clear it's a correct one.  Why does the user have this
expectation, and under what circumstances would they want e2fsck to
abort for some fixes, and automatically fix others, *and* want a full
set of messages of what was fixed?

If you are running things interactively (e.g., not at boot time),
having e2fsck abort for certain sets of error may end up wasting a lot
of time, since then you'll have to restart the e2fsck run.

Essentially, I'm asking for a complete justification for why this is a
general thing that many users will want, and why it makes sense for
them to want it.  The fact that *some* user had some twisted
expectation, and filed a Lustre bug, doesn't mean that you
automatically get to have that expectation satisified in the upstream
e2fsprogs sources.  You need to justify why other users would want it,
and how this is optimal for that particular way that people would want
to run e2fsck, for some particular set of circumstances.

Otherwise, some other user will have some *other* set if expectations,
and file another bug with Debian or Red Hat, demanding some other
random change, and this way lies madness.

					- Ted