Re: kernel BUG: kernel bug caught at 55% mark of portage cache update

[Chris Mason <chris.mason@oracle.com>]

On Fri, 2008-12-19 at 17:24 +0100, Julian Andres Klode wrote:
> 2008/12/19 Chris Mason <chris.mason@oracle.com>:
> > On Tue, 2008-12-16 at 14:57 -0500, Thomas Harning wrote:
> >> A kernel 'BUG' was caught while I had compression enabled and was
> >> performing a 'portage' update on my gentoo installation (which had
> >> btrfs mounted for portage for some basic perf testing).  It has
> >> finished the rsync and was at the 55% mark of the portage cache
> >> update... if that helps at all.
> >>
> >> Inlined is the kernel bug output... + some extra debug info that had
> >> been spit out beforehand that i thought might be useful...
> >>
> >> didn't appear to be at that 85% freespace mark...
> >>
> >> should I attach a btrfs-image dump?
> >>
> >> /dev/mapper/vg-btrfsTest
> >>                        1.0G  309M  716M  31% /mnt/btrfsTest
> >>
> >
> > Looking at the logs, your disk really was full.  Btrfs breaks the disk
> > up into metadata and data chunks.  The allocator is much more efficient
> > when the chunks are fairly large (the default is 1GB), and for smaller
> > devices it tries to make them smaller.
> >
> > There is some tuning that needs to happen on the smaller devices to
> > better balance space between data and metadata.  In your case, the
> > metadata block groups were all full even though the data block groups
> > still had some empty space.
>
> I can reproduce this bug at the same location, simply by running
> bonnie++ on a 4GB btrfs partition. I
> already wrote this one week ago to this list (4 times), but it did not
> show up on the list.

Yes, btrfs does not deal with enospc very well.  This is next on my list
of major improvements to start on.

bonnie writes a fairly large file, as I wrote above you're running into
the chunk allocation schemes that split data and metadata.

-chris