linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Please review and comment, dealing with btrfs full issues
Date: Tue, 6 May 2014 21:43:39 +0000 (UTC)	[thread overview]
Message-ID: <pan$b249a$72d93c56$a58d7a0c$356c6a0f@cox.net> (raw)
In-Reply-To: 5367C551.6020604@swiftspirit.co.za

Brendan Hide posted on Mon, 05 May 2014 19:07:29 +0200 as excerpted:

> In your last example, a full rebalance is not necessary. If you want to
> clear all unnecessary chunks you can run the balance with -dusage=80
> (636GB/800GB~=79%). That will cause a rebalance only of the data chunks
> that are 80% and less used, which would by necessity get about ~160GB
> worth chunks back out of data and available for re-use.

I don't believe your reasoning is entirely valid.  In the pathologically 
extreme case, all data chunks are 80% plus one byte used, save for one 
that's empty, and a -dusage=80 balance will return just that one empty 
chunk (but as a consequence return real fast as there's nothing else to 
do), just the same as -dusage=0, but -dusage=81 would return the 20% 
expected, but would take as long as -dusage=100 (or simply -d).

OTOH, if all chunks but one are 100% full, with the remaining chunks 
empty, a balance with -dusage=0 will have (within one chunk, depending on 
how full it is) the same effect as -dusage=80, with both completing at 
the same fast speed and returning more chunks than expected.  But simple 
-d (or -dusage=100) would take much MUCH longer, but return nothing 
(well, within one chunk) more than the -dusage=0 would.

Actual results, therefore, depend on file AND chunk fragmentation and 
usage.  Using the autodefrag mount option should increase the likelihood 
of better results faster, at lower -Xusage= numbers, but the only way to 
be sure is to do a run with numbers you think look reasonable given the 
situation you are in and the time you're willing to wait, and then rerun 
it again if the results weren't good enough.

Your algorithm is certainly a good first approximation, but it's just 
that, an approximation.  People who want the balance over as soon as 
possible but are willing to retry if necessary, should probably try a 
lower usage= number, while those who are leaving on a trip in the morning 
and want it to run overnight, with little chance of redoing it if the 
results weren't good enough, should probably pick a higher usage= number, 
even perhaps usage=95 or the like, to recover as much space as possible, 
without wasting time rebalancing the chunks that really ARE 100% full 
already.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


      parent reply	other threads:[~2014-05-06 21:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-05 12:16 Please review and comment, dealing with btrfs full issues Marc MERLIN
2014-05-05 17:07 ` Brendan Hide
2014-05-05 17:09   ` Brendan Hide
2014-05-05 18:36   ` Calvin Walton
2014-05-06  4:41     ` Russell Coker
2014-05-06 12:19   ` Marc MERLIN
2014-05-06 16:30     ` Brendan Hide
2014-05-06 16:43       ` Hugo Mills
2014-05-07 14:09         ` David Sterba
2014-05-07 14:23           ` Smallest-n balance filter (was Re: Please review and comment, dealing with btrfs full issues) Hugo Mills
2014-05-07 14:50             ` David Sterba
2014-05-06 21:20       ` Please review and comment, dealing with btrfs full issues Duncan
2014-05-06 21:43   ` Duncan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$b249a$72d93c56$a58d7a0c$356c6a0f@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).