On 15/07/2015 16:43, Thomas Goirand wrote: > 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?
Hi Thomas, I'm offended by the mails you sent to me on that topic. They were disrespectful, condescending and uncooperative. Given that's the first and only time you communicated with me since you started packaging jerasure, it would be wise of you to hand over the package to someone better able to establish a productive and friendly discussion with upstream. Cheers > > Cheers, > > Thomas Goirand (zigo) > -- Loïc Dachary, Artisan Logiciel Libre
signature.asc
Description: OpenPGP digital signature
