On Oct 29, 2012, at 3:04 AM, Michael Kjörling <mich...@kjorling.se> 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--
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
