On Fri, Jan 06, 2012 at 07:12:16AM +1100, Dave Chinner wrote:

On Thu, Jan 05, 2012 at 02:45:00PM -0500, Chris Mason wrote:

quoted

On Thu, Jan 05, 2012 at 01:46:57PM -0500, Chris Mason wrote:

quoted

On Thu, Jan 05, 2012 at 10:01:22AM +1100, Dave Chinner wrote:

quoted

On Thu, Jan 05, 2012 at 09:23:52AM +1100, Chris Samuel wrote:

quoted

On 05/01/12 09:11, Dave Chinner wrote:

quoted

Looks to be reproducable.

Does this happen with rc6 ?

I haven't tried. All I'm doing is running some benchmarks to get
numbers for a talk I'm giving about improvements in XFS metadata
scalability, so I wanted to update my last set of numbers from
2.6.39.

As it was, these benchmarks also failed on btrfs with oopsen and
corruptions back in 2.6.39 time frame.  e.g. same VM, same
test, different crashes, similar slowdowns as reported here:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/11062

Given that there is now a history of this simple test uncovering
problems, perhaps this is a test that should be run more regularly
by btrfs developers?

Unfortunately, this one works for me.  I'll try it again and see if I
can push harder.  If not, I'll see if I can trade beer for some
diagnostic runs.

Aha, if I try it just on the ssd instead of on my full array it triggers
at 88M files.  Great.

Good to know.  The error that is generating the BUG on my machine is
-28 (ENOSPC).  Given there's 17TB free on my filesystem....

Yeah, same thing here.  I'm testing a fix now, it's pretty dumb.  We're
not allocating more metadata chunks from the drive because of where the
allocation is happening, so it is just a check for "do we need a new
chunk" in the right place.

I'll make sure it can fill my ssd and then send to you.

-chris