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.

> 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.

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to