On 28 Oct 2012 14:19 -0600, from lists@colorremedies.com (Chris Murphy):

Somehow for large storage I like the idea of time to "full." GB and
TB of storage is not really what we care about, it just seems that
way because it's what we're used to. (Not to imply that we don't
care about GB and TB at all, but I do think most people convert this
into a "how many more movies, how much more database growth" and how
much time remaining is just a generic variation on those things.
GB/TB remaining doesn't do that, *and* just by nature of the term it
connotes an absolute value with inflexible meaning. But free space
on btrfs is flexible/relative, not absolute.

There are two fairly big issues however that I can see having thought
a little about this that will need careful consideration before
deciding to go with a "time to full" scheme.

First, what if disk usage is actually decreasing over time? It should
be trivial to translate that to, say, something like "> 3 years", but
it's a case that needs to be taken into consideration.

Second, there should still be a way to answer the question "will this
amount of payload data fit here?". There are numerous valid reasons
for wanting to know whether you can store a given number of bytes in a
specific place. Of course, depending on various factors (compression
etc.) the amount of available space may decrease by less than the size
of the payload data, but that is only a nice bonus in that case.

At work, it isn't uncommon for my disk usage to vary up _and down_ by
several GB (on the order of 10% or so of the total used is far from
uncommon) inside the scope of a day. I'd like to see the statistical
algorithm that can take such wild fluctuations and produce any
meaningful metric of the amount of remaining space expressed as "time
to full".

*Perhaps*, to accomodate per-object replication settings, there could
be a command like "display free space for this directory" which can
take the specific directory's replication settings into account once
that has been implemented. It could display two figures: the amount of
payload data that could be stored in that directory without touching
any replication settings ("if I do 'cat /dev/random > ./here', how big
will the file become before I run out of space?"), as well as the
number of data bytes available (think "how big will it become if I
force SINGLE?").

Might that be a workable approach?

-- 
Michael Kjörling • http://michael.kjorling.se • michael@kjorling.se
                “People who think they know everything really annoy
                those of us who know we don’t.” (Bjarne Stroustrup)