On 28 Oct 2012 14:19 -0600, from li...@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 • mich...@kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
--
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
