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
| ||
|
Message-ID: <alpine.LFD.2.00.1303060753500.24359@localhost> 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
Powered by blists - more mailing lists