linux-ext4 - Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD

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:	Wed, 6 Mar 2013 08:13:55 +0100 (CET)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Stephen Warren <swarren@...dotorg.org>
cc:	"Theodore Ts'o" <tytso@....edu>, Chris Ball <cjb@...top.org>,
	linux-ext4@...r.kernel.org, Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD

On Tue, 5 Mar 2013, Stephen Warren wrote:

> Date: Tue,  5 Mar 2013 13:25:18 -0700
> From: Stephen Warren <swarren@...dotorg.org>
> To: Theodore Ts'o <tytso@....edu>
> Cc: Chris Ball <cjb@...top.org>, linux-ext4@...r.kernel.org,
>     Stephen Warren <swarren@...dia.com>
> Subject: [PATCH] mke2fs: restore verbose message for BLKDISCARD
> 
> From: Stephen Warren <swarren@...dia.com>
> 
> mke2fs on a large slow eMMC device may appear to hang while executing
> ioctl(BLKDISCARD). CTRL-C and CTRL-\ don't appear to respond, or respond
> extremely slowly. -v doesn't give any hints what's happening. Only strace
> is a clue. Make -v print some clues to make it easier to track down the
> apparent hang.
> 
> This change re-uses the original messages that were implemented as part
> of 5827d24 "mke2fs support for BLKDISCARD" in order to easily re-use the
> translations of that message. Note that this patch prints the first
> message before executing the IOCTL, so the user is told what's going on
> before the long wait.
> 
> Signed-off-by: Stephen Warren <swarren@...dia.com>

Note that you've added the message only around the first 4k discard
which is only used to test whether the device actually support the
discard... which is not very useful and it can not even know whether
the whole device discard will succeed/fail so it is misleading.

Moreover there actually is a message saying that we're "Discarding
device blocks" and it even shows the progress. The step in which
we're doing the discard (and update the progress) is given by
DISCARD_STEP_MB = 2048MB. And all that in non verbose mode as well.

So what's happening in your case is that your message will not be
written to the output stream (no newline) for some reason even though
that we call fflush() after fputs(). I am not sure how to fix it
though since I always find this stream buffering and fflush quite
confusing and it never worked properly for me...

-Lukas

> ---
> Note: I've left mke2fs running for a while now (tens of minutes on a 16GiB
> eMMC), and this IOCTL still hasn't completed. I'm not sure how long it's
> meant to take. Perhaps the long execution time is actually a kernel bug in
> the MMC core or our SDHCI driver.

As mentioned we're doing 2GB discard steps so the problem really
should not be on mkfs side. It is very much possible that the
discard implementation on the eMMC is terribly slow (which does not
surprise me). What is says about itself ?

grep . /sys/block/sda/queue/discard_*

> ---
>  misc/mke2fs.c |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/misc/mke2fs.c b/misc/mke2fs.c
> index bbf477a..defb932 100644
> --- a/misc/mke2fs.c
> +++ b/misc/mke2fs.c
> @@ -2272,7 +2272,20 @@ static int mke2fs_discard_device(ext2_filsys fs)
>  	 * we do not print numeric progress resulting in failure
>  	 * afterwards.
>  	 */
> +	if (verbose) {
> +		printf(_("Calling BLKDISCARD from %llu to %llu "),
> +			(unsigned long long)0,
> +			(unsigned long long)fs->blocksize);
> +		fflush(stdout);
> +	}
>  	retval = io_channel_discard(fs->io, 0, fs->blocksize);
> +	if (verbose) {
> +		if (retval)
> +			printf(_("failed.\n"));
> +		else
> +			printf(_("succeeded.\n"));
> +	}
> +
>  	if (retval)
>  		return retval;
>  	cur = fs->blocksize;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html