On 2017-09-24 10:08, Goffredo Baroncelli wrote:
On 09/24/2017 12:10 PM, Anand Jain wrote:
All my points are clear for this patchset:
I know I removed one function, and my reason is:
1) No or little usage
And it's anti intuition.
2) Dead code (not tested nor well documented)
3) Possible workaround
I can add several extra reasons as I stated before, but number of reasons won't
validate anything anyway.
End user convenience wins over the developer's technical difficulties.
Sorry, but I have to agree with Qu; there is no a big demand (other than Austin) for this
functionality; even you stated that "...at some point it may..."; until now the
UI is quite unfriendly (we should use a big enough device, and then cut it by hand on the
basis of the output of mkfs.btrfs)...
I will comment that I agree that it should not be the default. It's not
intuitive for most people, and as you say it's a niche feature. Just
removing it completely though with the above argument sounds very much
like trying to meet quotas for coding.
I fear that this is another feature which increase the complexity of btrfs (and
tools) with little or none usage....
On average? It only increases the complexity of mkfs once there's a fix
for the (theoretically trivial to fix) issue with it ignoring the fact
that the first 1MB of space is supposed to be untouched by BTRFS.
The work of Qu is a nice cleanup; I hope that this will be the direction which BTRFS will
takes: removing of "strange/unused" features improving the reliability of the
others.
The two are not inherently interdependent, and that argument doesn't
exactly hold up to scrutiny considering that mkfs is already perfectly
reliable even with this feature, and it does not compromise the
reliability of other features (again, once you fix the usage of the
reserved area at the beginning of the image).
--
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
