On Wed, Jun 17, 2015 at 09:13:08AM -0400, Vincent Olivier wrote:
> 
> > On Jun 16, 2015, at 8:14 PM, Chris Murphy <lists@colorremedies.com> wrote:
> > 
> > On Tue, Jun 16, 2015 at 5:58 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > 
> >> On a current kernel unlike older ones, btrfs actually automates entirely
> >> empty chunk reclaim, so this problem doesn't occur anything close to near
> >> as often as it used to.  However, it's still possible to have mostly but
> >> not entirely empty chunks that btrfs won't automatically reclaim.  A
> >> balance can be used to rewrite and combine these mostly empty chunks,
> >> reclaiming the space saved.  This is what Hugo was recommending.
> > 
> > Yes, as little as a -dusage=5 (data chunks that are 5% or less full)
> > can clear the problem and is very fast, seconds. Possibly a bit
> > longer, many seconds o single digit minutes is -dusage=15. I haven't
> > done a full balance in forever.
> 
> 
> Yes, on this 80% full 6x4TB RAID10 -dusage=15 took 2 seconds and relocated "0 out of 3026 chunks”.
> 
> Out of curiosity, I had to use -dusage=90 to have it relocate only 1 chunk and it took les than 30 seconds.
> 
> So I put a -dusage=25 in the weekly cron just before the scrub.

   In most cases, all you need to do is clean up one data chunk to
give the metadata enough space to work in. Instead of manually
iterating through several values of usage= until you get a useful
response, you can use limit=<n> to stop after <n> successful block
group relocations.

   Hugo.

-- 
Hugo Mills             | Alert status mauve ocelot: Slight chance of
hugo@... carfax.org.uk | brimstone. Be prepared to make a nice cup of tea.
http://carfax.org.uk/  |
PGP: E2AB1DE4          |