On Mon, Oct 22, 2012 at 12:02:08AM -0600, Chris Murphy wrote: > > On Oct 21, 2012, at 10:32 PM, Chris Murphy <li...@colorremedies.com> wrote: > > > This is stock Fedora 18 beta kernel, 3.6.1-1.fc18.x86_64 #1 SMP Mon Oct 8 > > 17:19:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > > Probably not a good idea to omit this is a beta *test candidate* not a beta. > > Two things that make this possibly not realistic: > > 1. The virtual disks are obviously very small, 3GB each with the 4th one only > 12GB. > > 2. The original 3 device volume was ~97% full with a single large file prior > to adding the 4th device. Approximately 313MB free space remained on the > volume.
I'm not entirely sure what's going on here(*), but it looks like an awkward interaction between the unequal sizes of the devices, the fact that three of them are very small, and the RAID-0/RAID-1 on data/metadata respectively. You can't relocate any of the data chunks, because RAID-0 requires at least two chunks, and all your data chunks are more than 50% full, so it can't put one 0.55 GiB chunk on the big disk and one 0.55 GiB chunk on the remaining space on the small disk, which is the only way it could proceed. You _may_ be able to get some more success by changing the data to "single": # btrfs balance start -dconvert=single /mountpoint You may also possibly be able to reclaim some metadata space with: # btrfs balance start -m /mountpoint but I think that's unlikely. Hugo. (*) It may be an as-yet-undiscovered reservation problem, in which case you get to see Josef scream loudly and hide under his desk, gibbering. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- If it ain't broke, hit it again. ---
signature.asc
Description: Digital signature
