On Oct 29, 2012, at 3:04 AM, Michael Kjörling [off-list ref] wrote:

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.

Yes it should.

Second, there should still be a way to answer the question "will this
amount of payload data fit here?".

I agree. Time to full is just one possible way of being more forward thinking with large file systems.

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".

I think you'd something like CPU load balancing stats. An estimate based on today's usage, vs the past 2 weeks, or something. You wouldn't get just one estimate. It'd supply a context and thus give you a range of times to full depending on context, which hopefully the user knows something about.

*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?

Seems reasonable.


Chris Murphy