On 07/09/2015 11:35 PM, Loic Dachary wrote: > > > On 07/07/2015 18:24, James Page wrote: >> On 06/07/15 18:23, James Page wrote: >>>> The ceph Debian package git repository only contains very little >>>>> reasoning about the change. James can you please expand on this >>>>> a bit? In general I would prefer to have changes like this in >>>>> their own commit and not mixed with unrelated changelog >>>>> updates. Did the Hammer release not build with the jerasure in >>>>> Debian or are you just afraid of unexpected results if the >>>>> Debian package is built with another version of jerasure than >>>>> what they ship in their source code? These would IMO be valid >>>>> reasons to (temporarily) remove the patch. >>> Re-basing the patch - which was turning out to be non-trivial - >>> pushed me over the time I had todo this update; as the upload was >>> to experimental only, I intended to revisit when time permitted. >> >> I dug into this in a bit more detail today; the Ceph package builds a >> number of difference loadable erasure coding plugins, enabling >> different cpu feature sets (generic, neon, sse3, sse4); each time >> Jerasure and gf-complete are statically linked into the module, built >> with the required flags to enable the right CPU instruction codes >> (build time, not runtime enablement). > > Yes, and depending on which CPU features are available at runtime, > the plugin that can take advantage of them is loaded. All variants > are verified to encode / decode exactly in the same way (with a set > of data) each time a new Ceph version is published, to protect > against regression or corruption.
Such a feature should be upstreamed in gf-complete and jerasure. >> Unless I'm reading the packaging wrong, the jerasure and gf-complete >> packages current disable any CPU specific extensions in order to have >> a completely generic library that works on any CPU. So using the >> system libraries effectively cripples any CPU optimization that might >> be achievable at runtime in Ceph. > > Yes. I could fix that without sacrificing test coverage / data > integrity, simply by moving part of the above in the package, and > running integration and non regression tests on the resulting package. > The package could be used in the current Ceph integration suites, > before being uploaded to Debian GNU/Linux. That's the most effective > way to protect jerasure users against data loss right now. Could you please share your patches and open a bug against the gf-complete and jerasure packages? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
