On Tue, May 16, 2023 at 09:22:31PM +0100, Richard W.M. Jones wrote:
I'm not really sure we reached a conclusion so far, but I did
want to
say that I changed the evil filter impl so that it now treats any
0 <= P < 1e-12 as effectively 0. (P == evil-probability; P < 0 and P > 1
are still rejected at config time as before).
With P == 1e-12:
nbdkit: debug: evil: mode: stuck-bits, P: 1e-12
nbdkit: debug: evil: block_size: 17592186044416 (2**44)
nbdkit: debug: evil: expected bits per block: 140.737
(The large block size isn't an issue here as nothing is allocated.
However it would be a problem if the block_size calculation overflows,
and I believe that limiting P to larger values avoids this.)
To clarify what I meant ...
We aim to choose a block size where about 100 bits are corrupted in
the block, which limits the time taken when the code loops over the
block. Since the block size must also be a power of 2, it ends up
containing slightly more corrupted bits (on average 140 in the case
above).
The block size is calculated as the reciprocal of P. By limiting P to
be either "effectively 0", or in the range [1e-12 .. 1], we avoid
creating blocks larger than 2**44. If P < 1e-12 then it is handled by
a separate code path and treated as zero. If P > 1e-12 then the block
size will be smaller than above.
So my reasoning is that this should not overflow anything.
Also I'm not sure that handling probabilities as a numerator and
denominator actually helps here? Both still need to be stored as
floats, so it just pushes the same problem to the plugin.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v