Duncan <1i5t5.duncan <at> cox.net> writes:
[...]
> Normally you'd do a data balance to consolidate data in the data chunks
> and return the now freed chunks to the unallocated space pool, but you're
> going to have problems doing that ATM, for two reasons. The likely
> easiest to work around is that since all space is allocated and balance
> works by allocating new chunks and copying data/metadata from the old
> chunks over, rewriting, defragging and consolidating as it goes, but
> there's no space left to allocate that new one...
>
> The usual solution to that is to temporarily btrfs device add another
> device with a few gigs available, do the rebalance with it providing the
> necessary new-chunk space, then btrfs device delete, to move the chunks
> on the temporary-add back to the main device so you can safely remove the
> temporary-add. Ordinarily, even a loopback on tmpfs could be used to
> provide a few gigs, and that should be enough, but of course you can't
> reboot while the chunks are on that tmpfs-based loopback or you'll lose
> that data, and the below will likely trigger a live-lock and you'll
> pretty much HAVE to reboot, so having those chunks on tmpfs probably
> isn't such a good idea after all. But a few gig thumbdrive should work,
> and should keep the data safe over a reboot, so that's probably what I'd
> recommend ATM.
Thanks again for your input, Duncan.
What I did now was:
a) took another read on the matter first
b) verified the qemu-img'ed backup of the VM is working properly
c) deleted the original vm image and refreshed my system backups
At that point data was still fully allocated.
d) dropped that single system chunk as you suggested previously.
Interestingly this gave me:
Label: none uuid: 52bc94ba-b21a-400f-a80d-e75c4cd8a936
Total devices 1 FS bytes used 43.92GiB
devid 1 size 119.24GiB used 119.03GiB path /dev/sda2
..some free data chunks.
e) Ran an iteration with balance -dusage=5, -dusage=10, 15, 20, 25.
After 25 it looks like:
Label: none uuid: 52bc94ba-b21a-400f-a80d-e75c4cd8a936
Total devices 1 FS bytes used 43.92GiB
devid 1 size 119.24GiB used 95.02GiB path /dev/sda2
So, your suggestion regarding d) saved me from having to recreate the FS or
having to add a drive.
Now I need to make sure I get a notice when data gets filled up too much.
Regards,
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
