On 06/02/14 19:54, Goffredo Baroncelli wrote:
Hi Roman
On 02/06/2014 01:45 PM, Roman Mamedov wrote:
There's not a lot of code to include (as my 3-line patch demonstrates), it
could just as easily be removed when it's obsolete. But I did not have any
high hopes of defeating the "broken by design" philosophy, that's why I didn't
submit it as a real patch for inclusion but rather just as a helpful hint for
people to add to their own kernels if they want this change to happen.
I agree with you about the needing of a solution. However your patch to me
seems even worse than the actual code.
For example you cannot take in account the mix of data/linear and metadata/dup
(with the pathological case of small files stored in the metadata chunks ), nor
different profile level like raid5/6 (or the future raidNxM)
And do not forget the compression...
Just because the solution that Roman provided is not perfect does not
mean that it is no good at all. For common use cases this will give a
much better estimate of free space than the current code does, at a
trivial cost in code size.
It has the benefit of giving a simple estimate without doing any further
work or disk activity (no need to walk all chunks).
Adding a couple of more lines of code will make it work equally well
with other RAID levels, maybe that would be more acceptable?
Frank
--
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
