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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
