public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [3.2-rc2] loop device balance_dirty_pages_nr throttling hang
Date: Tue, 22 Nov 2011 21:49:21 +1100	[thread overview]
Message-ID: <20111122104921.GE8098@dastard> (raw)
In-Reply-To: <20111122102931.GD8098@dastard>

On Tue, Nov 22, 2011 at 09:29:31PM +1100, Dave Chinner wrote:
> I suspect the difference is that I was reproducing this with a used
> image file. It had somewhere in the order of 750MB of space used
> prior to running the test. I'd been using the image to test large
> filesystem support for xfstests. I'd done a bunch of testing with
> XFS on the loop device, and was trying to get the ext4 support to
> work when I was seeing these hangs. I manually ran the
> losetup/mount/mkfs loopdev/mount/falloc step to get it to hang.
> 
> So I think the state of the underlying image file has something to
> do with the hang. Most likely due to the IO rates, I think....
> 
> I'll try to reproduce it by running xfstests on XFS on it again
> before trying ext4 again (your script blew away the old image file I
> had). Alternatively, you can try writing lots of small random blocks
> to the image file before running the ext4 portion of the test.

At a rough approximation, the image file after xfs tests has run on
it for a while has somewhere on the high side of 30000 allocated
extents in it. So that could have significant impact on the layout
of the file and the IO patterns that result.

But, I just noticed that the discard that mkfs.ext4 will result in
all the extents being discarded in the underlying image file (due to
the fact the loopback device now supports hole punching), so the
previous state of the image file is getting trashed by the mkfs.ext4
execution, too. I think I already had a ext4 filesystem in some state
before I started running this manual prealloc test....

So, let me go back to running test 223 and then trying again with
having run mkfs on the loop device.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2011-11-22 10:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-21 14:20 [3.2-rc2] loop device balance_dirty_pages_nr throttling hang Dave Chinner
2011-11-22  3:56 ` Wu Fengguang
2011-11-22 10:29   ` Dave Chinner
2011-11-22 10:49     ` Dave Chinner [this message]
2011-11-22 13:17       ` Theodore Tso
2011-11-22 19:56         ` Dave Chinner

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=20111122104921.GE8098@dastard \
    --to=david@fromorbit.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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