On 04/07/2011 10:26 PM, Daniel J Blueman wrote:
Hi Josef, Chris,
On 8 April 2011 00:23, Josef Bacik<jo...@redhat.com> wrote:
On 04/07/2011 03:21 AM, Daniel J Blueman wrote:
When running a practical stress-test on 2.6.29-rc2 trying to reproduce
an older (extent refcounting) issue, I am consistently able to hit an
oops [] and an assertion failure [].
Sorry about that, please apply the patch I just sent this morning
[PATCH] Btrfs: deal with the case that we run out of space in the cache
Superb work - the btrfs_write_out_cache oops is addressed, so now we
(separately) hit a few other assertions at: volumes.c:2013 [1],
volumes.c:2063 [2] and volumes.c:2703 [3] with the previous
reproducer.
Let me know if adding any debugging or other testing may be useful.
Thanks,
Daniel
Looks like the first 2 panics are basically the same thing. You are
getting -EIO back from btrfs_shrink_device(), which could either come
from searching or it could come from the stuff in relocation.c. So will
you put printk's at the 2 places in relocation.c where we return -EIO
and figure out which one is getting tripped? Once we know who is
returning EIO we can go from there. As for the last one, that's just a
normal ENOSPC, but it's because we're allocating a chunk in the
submission path, so that's going to be a little trickier to deal with.
Lets fix these first two panics first and then hopefully that last one
will just go away :). Thanks,
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
