linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Lukáš Czerner" <lczerner@redhat.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>, Chris Ball <cjb@laptop.org>,
	linux-ext4@vger.kernel.org, Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCH] mke2fs: restore verbose message for BLKDISCARD
Date: Wed, 6 Mar 2013 08:13:55 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.00.1303060753500.24359@localhost> (raw)
In-Reply-To: <1362515118-30344-1-git-send-email-swarren@wwwdotorg.org>

On Tue, 5 Mar 2013, Stephen Warren wrote:

> Date: Tue,  5 Mar 2013 13:25:18 -0700
> From: Stephen Warren <swarren@wwwdotorg.org>
> To: Theodore Ts'o <tytso@mit.edu>
> Cc: Chris Ball <cjb@laptop.org>, linux-ext4@vger.kernel.org,
>     Stephen Warren <swarren@nvidia.com>
> Subject: [PATCH] mke2fs: restore verbose message for BLKDISCARD
> 
> From: Stephen Warren <swarren@nvidia.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@nvidia.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;
> 

  reply	other threads:[~2013-03-06  7:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05 20:25 [PATCH] mke2fs: restore verbose message for BLKDISCARD Stephen Warren
2013-03-06  7:13 ` Lukáš Czerner [this message]
2013-03-07 19:47   ` Stephen Warren
2013-03-08  7:23     ` Lukáš Czerner
2013-03-08 17:18       ` Stephen Warren
2013-03-08 19:00         ` Theodore Ts'o
2013-03-08 19:06           ` Theodore Ts'o
2013-03-08 19:08           ` Chris Ball
2013-03-08 20:03             ` Stephen Warren
2013-03-08 20:12               ` Chris Ball
2013-03-11 14:08           ` Eric Sandeen
2013-03-11 14:18             ` Lukáš Czerner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1303060753500.24359@localhost \
    --to=lczerner@redhat.com \
    --cc=cjb@laptop.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).