> On Jun 17, 2015, at 9:27 AM, Hugo Mills <h...@carfax.org.uk> wrote: > > On Wed, Jun 17, 2015 at 09:13:08AM -0400, Vincent Olivier wrote: >> >>> On Jun 16, 2015, at 8:14 PM, Chris Murphy <li...@colorremedies.com> wrote: >>> >>> On Tue, Jun 16, 2015 at 5:58 PM, Duncan <1i5t5.dun...@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.
Nice! Will do that instead! Thanks.
signature.asc
Description: Message signed with OpenPGP using GPGMail
