On Sun, May 11, 2014 at 04:11:56PM +0200, Brendan Hide wrote: > On 2014/05/11 11:52 AM, Russell Coker wrote: > >On Sun, 11 May 2014, Russell Coker <russ...@coker.com.au> wrote: > >>Below is the output of running a balance a few times on a 120G SSD. > >Sorry forgot to mention that's kernel 3.14.1 Debian package. > > > Please send the output of the two following command: > btrfs fi df / > > This will give more information on your current chunk situation. I suspect > this is a case where a system chunk (which is included when specifying > metadata) that is not actually being relocated. This is a bug that I believe > was already fixed, though I'm not sure in which version. > > The pathological case is where you have a chunk that is 1% full and *every* > other in-use chunk on the device is 100% full. In that situation, a balance > will simply move that data into a new chunk (which will only ever reach 1% > full). Thus, all subsequent balances will relocate that same data again to > another new chunk.
You're right about the system chunk, the message says it's blockgroup type '34', which matches SYSTEM (2) and DUP (32). Seems that the usage value does not propagate to the system group filter and just processes all its chunks each time, though all the metadata chunks are correctly filtered. -- 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
