Discussion:
BlaumRoth with w=7 : what are the consequences ?
Loic Dachary
2014-09-24 16:51:07 UTC
Permalink
Hi Kevin,

When implementing the plugin for Ceph, the check for isprime(w+1) was not added and w=7 was made the default for the BlaumRoth technique. As a result all content encoded with the BlaumRoth technique have used this parameter. I do not know what the consequences are. It does not crash and from what I've tried content can be encoded/decoded/repaired fine. But maybe I was lucky ?

Your expert opinion on the consequence of chosing w=7 would be greatly appreciated :-)

Cheers
--
Loïc Dachary, Artisan Logiciel Libre
Loic Dachary
2014-09-24 23:06:08 UTC
Permalink
Hi Kevin,

On 24/09/2014 20:40, Kevin Greenan wrote:> The constraint guarantees the MDS property. I believe there are conditions where w+1 is composite and you still have an MDS code, but there are restrictions on 'n' (codeword length). So, you may have chosen the right parameters. Did you verify all possible combinations of erasures is tolerated?

I tried all combinations that are likely to have been used and they all work out. Here is the script I used:

for w in 7 11 13 17 19 ; do for k in $(seq 2 $w) ; do for m in $(seq 1 $k) ; do for erasures in $(seq 1 $m) ; do ./ceph_erasure_code_benchmark --plugin jerasure --workload decoded --iterations 1 --size 4096 --erasures $erasures --parameter w=$w --parameter k=$k --parameter m=2 --parameter technique=blaum_roth ; done ; done ; done ; done

does that mean we're safe despite the fact that w+1 is not prime in all settings ?
For sake of safety, you probably do not want to get experimental with 'production' code. IMHO, you should put the check in, especially if 'n' is tunable.
n is tunable and the check is now enforced. I'm worried about the content that was previously encoded with codeword length that do not match prime(codeword + 1)

Cheers
--
Loïc Dachary, Artisan Logiciel Libre
Loading...