On 09/28/2012 01:20 PM, Hugo Mills wrote:
On Sat, Sep 29, 2012 at 12:02:23AM +0600, Roman Mamedov wrote:
On Fri, 28 Sep 2012 18:44:07 +0200
Goffredo Baroncelli<kreijack@xxxxxxxxx> wrote:
This means that the ration of space physically allocated on the disk and
the space available is 7GB/10GB = 0.7 . So on 135GB of disk, only 94GB
are available.
You assume metadata allocation will always grow linearly with data, which is
not true. So in my opinion it is not a good estimate.
No, but it's the best model we have right now. (And probably about
the best model we will have, without knowledge of the future
intentions of the user). Without inlining file data, the metadata is
dominated by checksums, which is a linear relationship (approx
1000:1). With inlining file data, metadata is probably dominated by
inline data; assuming the ratio of small-to-large files on the FS
remains unchanged in future, a linear relationship also applies. For
general usage, I'm happy to assume that the current ratio of data to
metadata will remain largely unchanged over the lifetime of the FS.
Since there really isn't a simple answer to how much free-space,
why not have the command print an upper and lower estimate and let
the user figure out how to interpret the numbers? This would inform
the user that there is some guesswork inherent in the estimation and
also provide an educated user with more exact numbers. Something
containing information such as:
Total: 135.00 GiB
Allocated: 10.51 GiB
Unallocated: 124.49 GiB
Free_Upper_Est: 130.00 GiB
Free_Lower_Est: 62.45 GiB
The main idea is that an informed user would know that the
upper-estimation would be for only writing, say, new data, while
the lower-estimation would be for writing everything in, say, a
RAID-1 subvolume. An uninformed user would (hopefully) realize
that he needs to read the Wiki's FAQ.
... and I've always found those hard to deal with in scripts. :)
(But they do have "plumbing" options, to use the git terminology,
so I'd be happy with having a parsable output option).
Hugo.
In 'df'/'du', -h is used for human-readable output while no options
is for easily parsable output.
Basically, I think that the bikeshed should be green. ;)
-Wade
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
