Description of problem:

Problems with handling numbers that mean sizes in libblockdev.

Version-Release number of selected component (if applicable):

0.6

How reproducible:

Quite.

Additional info:

1) Sizes can be larger than guint64 can accomodate, libblockdev needs to accomodate that in a _principled_ manner. An appropriate library should be explored for this, gmp might be an option. The fact of the matter is that when you add a bunch of numbers even if each is less than 2^64, you risk overflow. Every computation in libblockdev must address that fact. It might be possible to make use of introspection facilities to extract the necessary information from Size object after it has been passed to libblockdev plugin. blivet/bytesize Size class can be extended to provide methods that are required for this.
2) libblockdev should not be in the business of reading sizes from specs. The currently implemented mdraid and btrfs plugins use read_spec in order to return results from various interrogative methods for btrfs and mdraid. These methods should just read and chunk strings, somehow, and let client code decide how to
interpret the strings. Most places where size is determined statically I see something like "(1 MiB)", which I believe is some way of multiplying 1 by the numeric constant MiB. This is actually better than current approach in blivet/size, but is approximately what blockdev/size does. Of course, it will be necessary to make sure that (16 EiB) and others are handled nicely, i.e, (16 EiB) should not evaluate to 0.
3) There is no need to add additional named constants, e.g, PiB, TiB, unless they're actually used in the library.
4) Human readable is currently only used to eyeball some perfunctory C tests. So long as that's all its ever used for, there is no concern.
5) Tests which stress the plugins using sufficiently large values for sizes should be added to the test suite.
6) The use of floating point number in size computations should be eliminated (unless in human_readable, which doesn't matter unless the result is interpreted as a precise value somewhere, in which case it would have to be reevaluated). There are only a few of these, and I think they were eliminated
in devicelibs, so that might be a model.
7) Ad-hoc changes to blivet to ensure that blivet passes only values that are less than 2^^64 to libblockdev methods will compromise blivet without fixing the essential problem in libblockdev.