Am Fri, 09 Mar 2012 09:28:56 +0800
schrieb Liu Bo <liubo2...@cn.fujitsu.com>:
> On 03/09/2012 03:22 AM, Johannes Hirte wrote:
> > Am Tue, 6 Mar 2012 14:50:32 +0100
> > schrieb Johannes Hirte <johannes.hi...@fem.tu-ilmenau.de>:
> >
> >> I've backed up the filesystem, deleted the subvolumes, recreated
> >> them and copied the data back. Now everything seems to work again.
> >> I've also a full image of the damaged filesystem for further
> >> investigation. If someone has an idea for testing, I'm happy to try
> >> it.
> >
> > It's much worse than I thought. After a short time the same error
> > happened again (no space left on device). So recreated the
> > filesystem (mkbtrfs with default values) and copied the data from
> > the backup back, but the error still came back. I'm now on kernel
> > 3.2 which seems to work. I'll try to bisect the bad commit. For
> > info, df says:
> >
>
> OK, plz show us the results after your bisect, let's narrow down
> where goes wrong.
>
> thanks,
> liubo
Bisect points again to:
5500cdbe14d7435e04f66ff3cfb8ecd8b8e44ebf is the first bad commit
commit 5500cdbe14d7435e04f66ff3cfb8ecd8b8e44ebf
Author: Liu Bo <liubo2...@cn.fujitsu.com>
Date: Thu Feb 23 10:49:04 2012 -0500
Btrfs: increase the global block reserve estimates
When doing IO with large amounts of data fragmentation, the global
block reserve calulations are too low. This increases them to avoid
ENOSPC crashes.
Signed-off-by: Liu Bo <liubo2...@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.ma...@oracle.com>
The revision before is working and reverting this commit from master
works too. But as mentioned before, I'm not sure if this is root cause.
First time I've seen the error it happened without this patch too later
on.
--
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
