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
prev 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).