On 2014/05/07 09:59 AM, Marc MERLIN wrote:
[snip]
Did I get this right?
I'm not sure I did, since it seems the bigger the -dusage number, the
more work balance has to do.
If I asked -dsuage=85, it would do all chunks that are more than 15%
full?
-dusage=85 balances all chunks that up to 85% full. The higher the
number, the more work that needs to be done.
So, do I need to change the text above to say "more than 45% full" ?
More generally, does it not make sense to just use the same percentage
in -dusage than the percentage of total filesytem full?
Thanks,
Marc
Separately, Duncan has made me realise my "halfway up" algorithm is not
very good - it was probably just "good enough" at the time and worked
"well enough" that I wasn't prompted to analyse it further.
Doing a simulation with randomly-semi-filled chunks, "df" at 55%, and
chunk utilisation at 86%, -dusage=55 balances 30% of the chunks, almost
perfectly bringing chunk utilisation down to 56%. In my algorithm I
would have used -dusage=70 which in my simulation would have balanced
34% of the chunks - but bringing chunk utilisation down to 55% - a bit
of wasted effort and unnecessary SSD wear.
I think now that I need to experiment with a much lower -dusage value
and perhaps to repeat the balance with the df value (55 in the example)
if the chunk usage is still too high. Getting an optimal first value
algorithmically might prove a challenge - I might just end up picking
some arbitrary percentage point below the df value.
Pathological use-cases still apply however (for example if all chunks
except one are exactly 54% full). The up-side is that if the algorithm
is applied regularly (as in scripted and scheduled) then the situation
will always be that the majority of chunks are going to be relatively
full, avoiding the pathological use-case.
--
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
