lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 29 Apr 2019 07:16:36 +0300
From:   Alexey Lyashkov <alexey.lyashkov@...il.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Artem Blagodarenko <artem.blagodarenko@...il.com>,
        linux-ext4 <linux-ext4@...r.kernel.org>,
        Alexey Lyashkov <c17817@...y.com>
Subject: Re: [PATCH] e2fsck: Do not to be quiet if verbose option used.

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.


> 29 апр. 2019 г., в 2:38, Theodore Ts'o <tytso@....edu> написал(а):
> 
> On Fri, Apr 26, 2019 at 04:09:13PM +0300, Artem Blagodarenko wrote:
>> From: Alexey Lyashkov <c17817@...y.com>
>> 
>> e2fsck don't print a message if 'p' option used and error can be fixed without
>> user assistance,  but 'v' option asks to be more verbose, so user expect to
>> see any output. But not.
>> Fix this, by avoid message suppress with verbose option used.
>> 
>> Change-Id: I358e9b04e44dd33fdb124c5663b2df0bf54ce370
>> Signed-off-by: Alexey Lyashkov <c17817@...y.com>
>> Cray-bug-id: LUS-6890
> 
> I need to understand the use case of what you are trying to do here.
> The preen and verbose options were never intended to be mixed and this
> patch changes what the verbose flag does at a fairly fundamental
> level.  I'm not sure the results will be correct and they will almost
> certainly be surprising.
> 
> So (a) what is the user trying to do, and (b) what does the user want
> to be trying to do?  Preen was intended to be used as part of the boot
> process, when multiple e2fsck's would be running in parallel, and so
> you don't *want* much in the way of verbosity.
> 
>    	  	      	     	    - Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ