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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1303080818510.24359@localhost>
Date:	Fri, 8 Mar 2013 08:23:41 +0100 (CET)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Stephen Warren <swarren@...dotorg.org>
cc:	Lukáš Czerner <lczerner@...hat.com>,
	"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 Thu, 7 Mar 2013, Stephen Warren wrote:

> Date: Thu, 07 Mar 2013 12:47:09 -0700
> From: Stephen Warren <swarren@...dotorg.org>
> To: Lukáš Czerner <lczerner@...hat.com>
> 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 03/06/2013 12:13 AM, Lukáš Czerner wrote:
> > 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.
> 
> Oops. I certainly should looked at the code better.
> 
> > 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.
> 
> That said, it's that very first call to io_channel_discard() that is
> hanging then; I don't see the existing message at all. With my change, I
> do see the new message that I added. (So, no stdio flushing issue here).

It's just one fs block discard, are you sure about that ?

> 
> I will go investigate why this API is hanging. Sorry for the noise.
> 
> ...
> > 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_*
> 
> /sys/block/mmcblk1/queue/discard_granularity
> 0
> /sys/block/mmcblk1/queue/discard_max_bytes
> 512

Here is your problem. Doing discard of 16GB (or even one step of
2GB) on the slow device such the eMMC certainly is just 512B at a
time is expected to be *really* slow!

If you want to check out how fast/slow it actually is you can issue
discard directly on the device using blkdiscard toos which should be
part of the very recent util linux (not sure if it has been released
yet, but you can try git repository).

-Lukas

> /sys/block/mmcblk1/queue/discard_zeroes_data
> 1
> 
>