From: Dave Chinner <david@fromorbit.com>
To: Paolo Pisati <p.pisati@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: 3.5+, xfs and 32bit armhf - xfs_buf_get: failed to map pages
Date: Thu, 30 May 2013 10:42:15 +1000 [thread overview]
Message-ID: <20130530004215.GD29466@dastard> (raw)
In-Reply-To: <20130529135641.GB4889@luxor.wired.org>
On Wed, May 29, 2013 at 03:56:41PM +0200, Paolo Pisati wrote:
> On Thu, May 23, 2013 at 04:34:56PM +0200, Paolo Pisati wrote:
> > On Tue, May 21, 2013 at 10:02:09AM +1000, Dave Chinner wrote:
> > >
> > > And that fix I mentioned will be useless if you don't apply the
> > > patch that avoids the vmap allocation problem....
> >
> >
> > ok, so i recompiled a kernel+aforementioend fix, i repartitioned my disk and i
> > ran the swift-bench for 2 days in a row until i got this:
>
> i'm testing a 3.5.y kernel plus those 3 patches:
>
> 549142a xfs: don't use speculative prealloc for small files
> f0843f4 xfs: limit speculative prealloc size on sparse files
> 454da09 xfs: inode allocation should use unmapped buffers.
>
> and i can confirm that:
>
> -using a small fs (2G) i cannot reproduce any -ENOSPC or vmalloc() problem
> anymore, the benchmark runs until running out of inodes
>
> -using a bigger fs (~250G), two days and my tests are still running good
Ok, good to know. The first patch you list there hasn't even been
reviewed yet, so it might take some time before that is ready for
-stable backport.
Also, there are a bunch of fixes needed to the second patch you have
there (f0843f4 xfs: limit speculative prealloc...) that would also
be necessary for a -stable backport. i.e:
e8108ce xfs: fix xfs_iomap_eof_prealloc_initial_size type
e114b5f xfs: increase prealloc size to double that of the previous extent
e78c420 xfs: fix potential infinite loop in xfs_iomap_prealloc_size()
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-05-30 0:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-17 10:45 3.5+, xfs and 32bit armhf - xfs_buf_get: failed to map pages Paolo Pisati
2013-05-18 8:43 ` Jeff Liu
2013-05-19 1:13 ` Dave Chinner
2013-05-20 17:07 ` Paolo Pisati
2013-05-21 0:02 ` Dave Chinner
2013-05-23 14:34 ` Paolo Pisati
2013-05-29 13:56 ` Paolo Pisati
2013-05-30 0:42 ` Dave Chinner [this message]
2013-05-30 0:38 ` 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=20130530004215.GD29466@dastard \
--to=david@fromorbit.com \
--cc=p.pisati@gmail.com \
--cc=xfs@oss.sgi.com \
/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