Discussion:
Bug#791445: ceph: uses bundled "libjerasure" library again
(too old to reply)
Dmitry Smirnov
2015-07-04 23:38:35 UTC
Permalink
Package: ceph
Version: 0.94.2-1
Severity: serious

0.94.2-1 no longer uses "libjerasure". As per changelog entry:

d/p/use_system_jerasure.patch,d/control: Drop use of libjerasure
as the patch is intrusive and expensive to maintain; will revisit if
adopted upstream.

My reading of the above is that maintainer decided not to inconvenient himself
with maintaining existing patch because using system library is not important
enough?

I'm concerned about such attitude.
Please stop using bundled (in-)convenience copy and switch to system
"libjerasure" again.

Please remember about policy §4.13:

https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

Thanks.
--
All the best,
Dmitry Smirnov

---

Continuous effort - not strength or intelligence - is the key to unlocking
our potential.
-- Winston Churchill
Loic Dachary
2015-07-05 20:56:10 UTC
Permalink
Hi,

I'm co-maintainer of both jerasure and ceph. If the Debian jerasure package was orphaned, I would be happy to step in and maintain it as a standalone package. Jerasure was packaged without dialog with the jerasure upstream and I can understand that keeping it in sync with what ceph needs is significant work.

Cheers
Post by Dmitry Smirnov
Package: ceph
Version: 0.94.2-1
Severity: serious
d/p/use_system_jerasure.patch,d/control: Drop use of libjerasure
as the patch is intrusive and expensive to maintain; will revisit if
adopted upstream.
My reading of the above is that maintainer decided not to inconvenient himself
with maintaining existing patch because using system library is not important
enough?
I'm concerned about such attitude.
Please stop using bundled (in-)convenience copy and switch to system
"libjerasure" again.
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
Thanks.
_______________________________________________
Ceph-maintainers mailing list
http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com
--
Loïc Dachary, Artisan Logiciel Libre
Gaudenz Steinlin
2015-07-06 14:46:22 UTC
Permalink
[ Adding the jerasure maintainer to the CC ]

Hi
Post by Loic Dachary
Hi,
I'm co-maintainer of both jerasure and ceph. If the Debian jerasure
package was orphaned, I would be happy to step in and maintain it as a
standalone package. Jerasure was packaged without dialog with the
jerasure upstream and I can understand that keeping it in sync with
what ceph needs is significant work.
Loic thanks for your offer to help with this. We definitively need some
upstream assistence on this. IMO while the current approach to just use
the bundled version is suboptimal, the previous approach to just
unilaterally use a different version of jerasure than upstream is not
good either.

Currently ceph is AFAICS the only reverse dependency of jerasure. I
don't know why Thomas packaged it in the first place. But if we want to
keept the standalone package it might be the best for the ceph
maintainers group to take over maintenance of the jerasure Debian
package. I hope Thomas won't mind if we lower the burden for him a bit.

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.

What's the ceph upstream position on splitting out jerasure and building
against the standalone version? Is this considered supported? Are you
willing to accept a patch which either uses a standalone jerausre for
all builds or which introduces a configure flag to do so?

As I understand the current situation the jerasure code is a submodule
inside the ceph git repository and referencing a special v2-ceph
branch. Is this going to stay like this or are you planing on
integrating all this into jerasure and making this tight coupling
obsolete.

From a Distribution packagers standpoint the current situation is less
than optimal. I would very much prefer to not have third party libraries
bundled in the source code. But without upstream cooperation this is
hard to solve, more so as the bundled library is also a modified version
of the original jerasure code.

BTW all said above similarly applies to gf-complete. I think these two
dependencies have to be resolved in the same manner.

Gaudenz
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
James Page
2015-07-06 17:23:02 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/07/15 15:46, Gaudenz Steinlin wrote:
[...]
Post by Gaudenz Steinlin
Post by Loic Dachary
I'm co-maintainer of both jerasure and ceph. If the Debian
jerasure package was orphaned, I would be happy to step in and
maintain it as a standalone package. Jerasure was packaged
without dialog with the jerasure upstream and I can understand
that keeping it in sync with what ceph needs is significant
work.
Loic thanks for your offer to help with this. We definitively need
some upstream assistence on this. IMO while the current approach to
just use the bundled version is suboptimal, the previous approach
to just unilaterally use a different version of jerasure than
upstream is not good either.
Currently ceph is AFAICS the only reverse dependency of jerasure.
I don't know why Thomas packaged it in the first place. But if we
want to keept the standalone package it might be the best for the
ceph maintainers group to take over maintenance of the jerasure
Debian package. I hope Thomas won't mind if we lower the burden for
him a bit.
I can help there - OpenStack Swift has erasure coding support as of
2.3.0; Thomas packaged Jerasure for this purpose.
Post by Gaudenz Steinlin
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 also need to catchup on getting the 'modules' patch upstreamed;
that's also awkward with every Ceph release.
Post by Gaudenz Steinlin
What's the ceph upstream position on splitting out jerasure and
building against the standalone version? Is this considered
supported? Are you willing to accept a patch which either uses a
standalone jerausre for all builds or which introduces a configure
flag to do so?
I would prefer to see this approach taken; I hope upstream would be
supportive.


- --
James Page
Ubuntu and Debian Developer
***@ubuntu.com
***@debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVmrl2AAoJEL/srsug59jD3mQQALNGnqV+Z18zkmi8qf1di69d
Y3rRmmE26/uPsKjpUPxFxLDSZjPTteT1HhrNeIukoWGdXWfTnMBLTgz18Vy7fgG+
kFPd20VYOpO2BHpgkStK8dvjKVu0TA5BNXfMGy/Hv7Ap6oad/vc8siQHm4zFOAyA
+oqHKcCTulPBBSCiQfop2va270Nx0ynkiNq7aK2R80G3wl0REhG0+RIQOef4N1Zf
QnL/ZvAcwVBMLRqBBUDPfr0AdL2h5Ddq+4o9ub3w5xmI7W4aGQlIrJCjLc4dqvaV
sXeVo44mpJmtHIl3QYNxJQ80iPa6PXQCWq+OiGnFGIqCQRHNGgX04PR5mM8108El
429f8zDTAA/zBsEagnGNTkLPGYiaIglC8XtqONALEmVLe7J4fHA8qubYoZbM0imL
8FTg7wK5ysWge+pkwCzp/iWz5swoWiZikKQ+cuvm8R+nCdcWL+6E8Cba7XhVJSFG
AYwnNtzseaOSbQjNLr0L6wGUR+eZJugCDvXAh7zi9UF0Qnot+CVmVHBP3SALJkrD
9jOE/lU5BiUVDnNdTahJeZ6qwO7GfL9vrUUy87E7VupmoD2dzbht3QSS11VKGTpM
/Zh/bkt6vCp1HMyVBMfLPO9StHDY6KFCrm0/RmAhB1AbDawFM6lGeUprJggoBMSk
sCGX4t3vrGgiXVCZ6WDI
=Hz2B
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
James Page
2015-07-07 16:24:05 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by James Page
Post by Gaudenz Steinlin
The ceph Debian package git repository only contains very little
Post by Gaudenz Steinlin
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).

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.


- --
James Page
Ubuntu and Debian Developer
***@ubuntu.com
***@debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVm/0lAAoJEL/srsug59jD/EsP/iageGQ/sd+1jE5Suz+dhLoP
+6w8xlHyBYKFM7mDqE39+CZN6OsBO/edjt9WuGdfyWMwSIa6cc9T1w/rwCtu+hU/
DAtBxXh9yQuq6SP7A1ER1v3Q0jJ/tCEkqO/wsGZ5XgjE4jB2jjiYRkl17CtNShSg
oC2cf2khp5LcIa4V1RFoZQstVVXCWryY22F+u0HGm4wqRVwBU5Iihpb5GR0kwcxk
0zLEy9yar9EmicztMW4iWFfk5j8jcHWTQz0SejzrfFd1Nxm7xKyDKxhC7ybJPpXP
iZ0wQKKnuPcr5Ix90IgmUqMjt8wGD9q3e5zhHtL4sajoF9nNSftWlWbd4MedDosU
KTHz3SaLAkLeJ8694tOfUoYNfQ+YS73gd47DOz1fjixaUZaVXXsS/WY8DKS01g1r
NZeQ+NNwfiPIkQxUTv40xLas2yzVwHmQEjYe9xvIny8fvsEJ7j2alS56zQn6qB44
KCfnrfQh0DLsD3RqcuAWOqGTCymiFlj741HZQEEvWF5ADsyEentSvpTT9Q4w1CBD
F+boqsMKqR9nYwy6RfqqGtW1rRHF13tOUgMmaleiGY9BtMgfSb1Iiq9hWlSmp+rF
1BsUUumoeQKUto8GBW5yodHBJoHS+JRbF7uZl2ZKGvFG9RJAuGdsQCjL8iGhLfh5
URYktR/1Bp+5y6mO8wNe
=r3uE
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gaudenz Steinlin
2015-07-08 07:37:32 UTC
Permalink
severity 791445 normal
retitle 791445 Use system libjerasure with CPU optimizations
thanks
Post by James Page
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by James Page
Post by Gaudenz Steinlin
The ceph Debian package git repository only contains very little
Post by Gaudenz Steinlin
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).
Loic, are there plans upstream to change this? To me the best solution
would be to move the runtime detection into jerasure and gf-complete and
then to dynamically link against these. With this other consumers of
jerasure could also benefit from this and it would make the life of
distribution package maintainers much easier.

But then I don't know if there are technical reasons why it was
implemented that way in the first place.
Post by James Page
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.
Considering this I think using the system jerasure is not an option in
it's current state. Removing all CPU optimization does not look like the
right thing to do. I set the bug severity and title accordingly.

This does not mean that this bug does not need fixing. A solution to
have both CPU optimizations and dynamic linking against the system
library would be much prefered. But in the current state just reverting
to use the system library does not look like the right thing to do.

Gaudenz
Thomas Goirand
2015-07-09 21:15:55 UTC
Permalink
Post by James Page
Post by James Page
Post by Gaudenz Steinlin
The ceph Debian package git repository only contains very little
Post by Gaudenz Steinlin
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).
I really wish gf-complete & jerasure had runtime checks for the CPU
type, because I had to disable all SSE stuff, since it isn't available
on all Intel CPUs. :(
Post by James Page
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.
Correct.
Post by James Page
So using the
system libraries effectively cripples any CPU optimization that might
be achievable at runtime in Ceph.
Yes. The way it should be fixed is by fixing upstream code to do runtime
checks, or just rebuilding the libraries without the SSE disable
patches. The fact that SSE is disabled in Debian & Ubuntu is certainly
not a valid reason to hack and embed the libs in Ceph. IMO we shall talk
to upstream about this issue and get it solved there, probably by a
contribution to gf-complete & jerasure. If shere was such patch
available, I'd include it in the Debian package, even if it wasn't
available in a new upstream release.

Cheers,

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loic Dachary
2015-07-09 21:35:07 UTC
Permalink
Post by James Page
Post by James Page
Post by Gaudenz Steinlin
The ceph Debian package git repository only contains very little
Post by Gaudenz Steinlin
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.
Post by James Page
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
Thomas Goirand
2015-07-15 14:43:26 UTC
Permalink
Post by Loic Dachary
Post by James Page
Post by James Page
Post by Gaudenz Steinlin
The ceph Debian package git repository only contains very little
Post by Gaudenz Steinlin
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.
Post by Loic Dachary
Post by James Page
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-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loic Dachary
2015-07-15 16:30:39 UTC
Permalink
Post by Thomas Goirand
Post by Loic Dachary
Post by James Page
Post by James Page
Post by Gaudenz Steinlin
The ceph Debian package git repository only contains very little
Post by Gaudenz Steinlin
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.
Post by Loic Dachary
Post by James Page
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
Post by Thomas Goirand
Cheers,
Thomas Goirand (zigo)
--
Loïc Dachary, Artisan Logiciel Libre
Thomas Goirand
2015-07-15 22:26:38 UTC
Permalink
Post by Loic Dachary
Post by Thomas Goirand
Post by Loic Dachary
Post by James Page
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.
Post by Loic Dachary
Post by James Page
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 chommunicated 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.
Well, disrespect is what you get when you are disrespectful yourself.
Asking to hand-over the package for no valid reason, with no bug opened
at all, after all the effort and time I spent on these was really
disrespectful indeed. You still haven't opened any bug btw, please do so
if you have any concern.

Now I fail to see how uncooperative I have been. I've been here asking
you to share your work within the packages of gf-complete, and jerasure,
but it doesn't seem like you want to. In what way is this an
uncooperative attitude from my side? Just because I refuse to hand-over
the packages to you (only, without a team)? Or is this because I've told
you that it should be upstream to do runtime CPU feature detection? The
only answer I get is that I'm "disrespectful, condescending and
uncooperative" in return. This isn't going in the right direction.

I by the way would like to point out that you are still a member of the
OpenStack packaging group on Alioth, where all of these packages are
maintained. So if you would like to contribute, the git repositories are
wide open to you. I don't understand why I would have to just give-up
the packages to you and you only. No, these packages are *not* getting
away from the OpenStack packaging group. Yes, you can help or even take
care of them if you wish. I've always been very welcoming contributors,
but we need to keep this kind of key package in the group to make sure
they are well integrated with everything else in OpenStack.

In the past, communicating with you was done in a very friendly way. I
don't understand what happened suddenly. What I feel from my side is
aggressiveness from yours. So I propose that we both forget it, and try
to reboot all. If I offended you, I'm sorry about it. I hope you'll
forget it, and I'll try to forgive you too.

Shall we move on? Can we have a constructive conversation from now on?

Let me do another attempt, and see how it goes: what's your plan for the
packages to do CPU feature detection at runtime, and get Ceph to use
that, instead of embedding the libs?

I also have plans myself, btw, but I was lacking time. I know there's
some ways to add CPU features built in libs (dropped in specific
folders). Another way would be to have another binary including the
optimizations (which we could call for example libgf-complete1-sse4, and
which would Provides: and Breaks: libgf-complete1).

I'd prefer the first approach, but I never had time to investigate how
it's done in Debian. There's also the issue that some buildd may not
have the SSE4 features, and therefore, they may not be able to build the
packages. This would have to be investigated too.

I'm looking forward to read your answer, then let's see together how it
can happen.

Cheers,

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thomas Goirand
2015-07-07 23:53:15 UTC
Permalink
Post by Gaudenz Steinlin
[ Adding the jerasure maintainer to the CC ]
Hi
Post by Loic Dachary
Hi,
I'm co-maintainer of both jerasure and ceph. If the Debian jerasure
package was orphaned, I would be happy to step in and maintain it as a
standalone package. Jerasure was packaged without dialog with the
jerasure upstream and I can understand that keeping it in sync with
what ceph needs is significant work.
Loic thanks for your offer to help with this. We definitively need some
upstream assistence on this. IMO while the current approach to just use
the bundled version is suboptimal, the previous approach to just
unilaterally use a different version of jerasure than upstream is not
good either.
Currently ceph is AFAICS the only reverse dependency of jerasure. I
don't know why Thomas packaged it in the first place. But if we want to
keept the standalone package it might be the best for the ceph
maintainers group to take over maintenance of the jerasure Debian
package. I hope Thomas won't mind if we lower the burden for him a bit.
I packaged it because it's needed by python-pyeclib, itself needed by
the latest Swift. No, I don't wish to hand-over its maintainership, but
I do accept contributions within the OpenStack packaging group on Alioth.
Post by Gaudenz Steinlin
From a Distribution packagers standpoint the current situation is less
than optimal. I would very much prefer to not have third party libraries
bundled in the source code. But without upstream cooperation this is
hard to solve, more so as the bundled library is also a modified version
of the original jerasure code.
Outch! Talking with upstream is indeed important here. FYI, I had to
battle the pyeclib upstream also, so that they don't embbed the package.
Having gf-complete and libjerasure early in Debian helped to convince
them, so I am happy I did the work early.

Cheers,

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loic Dachary
2015-07-08 09:07:43 UTC
Permalink
Hi,

Without integration tests, linking Ceph against the wrong jerasure version may lead to data loss. Prior to publishing a Ceph version, various integration tests run to verify encoding / decoding, this is the main incentive to have jerasure as part of Ceph. The other reason is that jerasure can be optimized for SIMD instructions (ARM / INTEL) and not doing so significantly impacts performances.

Cheers
Post by Thomas Goirand
Post by Gaudenz Steinlin
[ Adding the jerasure maintainer to the CC ]
Hi
Post by Loic Dachary
Hi,
I'm co-maintainer of both jerasure and ceph. If the Debian jerasure
package was orphaned, I would be happy to step in and maintain it as a
standalone package. Jerasure was packaged without dialog with the
jerasure upstream and I can understand that keeping it in sync with
what ceph needs is significant work.
Loic thanks for your offer to help with this. We definitively need some
upstream assistence on this. IMO while the current approach to just use
the bundled version is suboptimal, the previous approach to just
unilaterally use a different version of jerasure than upstream is not
good either.
Currently ceph is AFAICS the only reverse dependency of jerasure. I
don't know why Thomas packaged it in the first place. But if we want to
keept the standalone package it might be the best for the ceph
maintainers group to take over maintenance of the jerasure Debian
package. I hope Thomas won't mind if we lower the burden for him a bit.
I packaged it because it's needed by python-pyeclib, itself needed by
the latest Swift. No, I don't wish to hand-over its maintainership, but
I do accept contributions within the OpenStack packaging group on Alioth.
Post by Gaudenz Steinlin
From a Distribution packagers standpoint the current situation is less
than optimal. I would very much prefer to not have third party libraries
bundled in the source code. But without upstream cooperation this is
hard to solve, more so as the bundled library is also a modified version
of the original jerasure code.
Outch! Talking with upstream is indeed important here. FYI, I had to
battle the pyeclib upstream also, so that they don't embbed the package.
Having gf-complete and libjerasure early in Debian helped to convince
them, so I am happy I did the work early.
Cheers,
Thomas Goirand (zigo)
--
Loïc Dachary, Artisan Logiciel Libre
Dmitry Smirnov
2015-07-08 13:07:50 UTC
Permalink
Post by Loic Dachary
Without integration tests, linking Ceph against the wrong jerasure version
may lead to data loss. Prior to publishing a Ceph version, various
integration tests run to verify encoding / decoding,
Those check are part of post-build tests, right?

While I was maintaining Ceph I've made changes to run unit tests but James
reverted it as well. :(
Post by Loic Dachary
this is the main incentive to have jerasure as part of Ceph.
I'm sure Thomas can enable optimisations in jerasure library.
Post by Loic Dachary
The other reason is that
jerasure can be optimized for SIMD instructions (ARM / INTEL) and not
doing so significantly impacts performances.
Once again, this seems to be an improvement suggestion for libjerasure rather
than argument against using system library.
--
All the best,
Dmitry Smirnov.

---

All that is necessary for the triumph of evil is that good men do nothing.
Loic Dachary
2015-07-08 13:57:41 UTC
Permalink
Hi Dmitry,
Post by Dmitry Smirnov
Post by Loic Dachary
Without integration tests, linking Ceph against the wrong jerasure version
may lead to data loss. Prior to publishing a Ceph version, various
integration tests run to verify encoding / decoding,
Those check are part of post-build tests, right?
Part of them are run with make check, others via teuthology and require multiple machines to deploy an actual cluster. Every binary combination of Ceph + jerasure + gf_complete must be tested in this way to verify non regression that could lead to permanent data loss. The process is not very complex but it requires a little infrastructure and attention to details.
Post by Dmitry Smirnov
While I was maintaining Ceph I've made changes to run unit tests but James
reverted it as well. :(
Even if not done as part of a regular dpkg-buildpackage, make check is a must have. Although it is run many times a day, it is sensitive to the configure flag combination.
Post by Dmitry Smirnov
Post by Loic Dachary
this is the main incentive to have jerasure as part of Ceph.
I'm sure Thomas can enable optimisations in jerasure library.
Post by Loic Dachary
The other reason is that
jerasure can be optimized for SIMD instructions (ARM / INTEL) and not
doing so significantly impacts performances.
Once again, this seems to be an improvement suggestion for libjerasure rather
than argument against using system library.
I'm not saying it's impossible. Jerasure has been packaged for quite some time now and no effort has been made to address these issues. Hence my proposal to work on the packages if they were orphaned. Although I could teach Thomas or someone else how and why this should be done, I don't have that kind of time right now. Working on the package is less time consuming.

Cheers
--
Loïc Dachary, Artisan Logiciel Libre
Dmitry Smirnov
2015-07-08 14:13:53 UTC
Permalink
Post by Loic Dachary
Jerasure has been packaged for quite some
time now and no effort has been made to address these issues. Hence my
proposal to work on the packages if they were orphaned. Although I could
teach Thomas or someone else how and why this should be done, I don't have
that kind of time right now. Working on the package is less time
consuming.
I reckon it is between you and Thomas. :)

One of the reasons why I like standalone library is that it can run its own
tests as well -- a something rarely seen in bundled (statically linked)
libraries. Unfortunately at the moment "libjerasure" package do not run any
tests... :(
--
All the best,
Dmitry Smirnov.
Thomas Goirand
2015-07-09 21:27:31 UTC
Permalink
Post by Dmitry Smirnov
Post by Loic Dachary
Jerasure has been packaged for quite some
time now and no effort has been made to address these issues. Hence my
proposal to work on the packages if they were orphaned. Although I could
teach Thomas or someone else how and why this should be done, I don't have
that kind of time right now. Working on the package is less time
consuming.
I reckon it is between you and Thomas. :)
One of the reasons why I like standalone library is that it can run its own
tests as well -- a something rarely seen in bundled (statically linked)
libraries. Unfortunately at the moment "libjerasure" package do not run any
tests... :(
There's no question asked here. Embedding a library which is at the same
time available standalone is a RC bug (severity: serious, because of a
strong policy violation) which shall be fixed asap (so the severity of
the bug is correct).

Cheers,

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
James Page
2015-07-10 12:19:49 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by Thomas Goirand
Post by Dmitry Smirnov
One of the reasons why I like standalone library is that it can run its own
Post by Dmitry Smirnov
tests as well -- a something rarely seen in bundled (statically
linked) libraries. Unfortunately at the moment "libjerasure"
package do not run any tests... :(
There's no question asked here. Embedding a library which is at the
same time available standalone is a RC bug (severity: serious,
because of a strong policy violation) which shall be fixed asap (so
the severity of the bug is correct).
Actually I don't think this is a RC bug - policy says 'should' not 'must
'.

I agree that having a single libjerasure etc... is preferably, but at
the same time, the way the build works (multiple, cpu optimized
plugins including jerasure and gf-complete) in Ceph and how it *does*
do runtime detection of CPU features means that if we switch now to
using libjerasure, we cripple Ceph performance on any reasonably
specified server for users who want to use erasure coding.

I'd actually feel compelled to raise an RC bug against Ceph being
fundamentally broken in this area if this where the case.

Switch to libjerasure/gf-complete? - yes - when? when its possible
todo the correct runtime determination of CPU features in these
codebases, and we're able to make Ceph build and use this effectively.

So not yet...

- --
James Page
Ubuntu and Debian Developer
***@ubuntu.com
***@debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVn7hlAAoJEL/srsug59jDMYYP/ivUsNw2RBPlvJkPDgvfcPke
h2dE6xrETy4me2+9V2dVkSnQhxNpOJjNUezagfZJ1aD9D0c5DpW2qZqlDlhJI6Cp
dk4VxMD3NCBMRaBO0TmhfO4t21L5FAyjRS5DZ8VHrUvXVMfxZFZ6DbD1uXhowega
1pE67bXWSsXEu1yOhZTqLbdx26mBtOSPyS4VXfHofY5xlDnneJBbD85nEKi37VT9
Sbbiy3CPWzGf6mIFlQbxDUSDoaQuXY8ZMkMX+RdkCloLmy1QSDJzU6Folhe8Aba7
2yjOHzHrgykm6x2YB/HaLgBctgcz21US2SuX4Y3IXHHXqnKL8dZpkWQLFawwpWTf
npSmya/P/ThxAQ3Ra/9FwJMGhvzRjdftsmoIq0jwGV7Xl41CqgAlSIll5u+wWlr0
mVKY3tFanAH0WdXx9qOfO2eLCx9bOuhm9D6xrQufeFTipVeeARZwPCQdWpbCWN94
kHxrZz6MUb8+CW86CtKRhiVR4xCDK1NJzgAkrMMnRD+Z/BW5FqPQB7dJFoD4dX0s
xiHlFTGXdweorsus7MHiw0Ylhp7/AFwshn0DjsXI0fXv9hMvWigSUCjIH1hK8GKD
tyK0TlYu3JtGKL33NczN5mGQe5Hg76ejGpHGSqp8EthZCDeNZhHy1dq6wFUrYQ6M
3LKDAuwK4/PlpVVXkj6r
=1/Bp
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thomas Goirand
2015-07-09 21:25:09 UTC
Permalink
Post by Loic Dachary
Post by Dmitry Smirnov
Post by Loic Dachary
The other reason is that
jerasure can be optimized for SIMD instructions (ARM / INTEL) and not
doing so significantly impacts performances.
Once again, this seems to be an improvement suggestion for libjerasure rather
than argument against using system library.
I'm not saying it's impossible. Jerasure has been packaged for
quite some time now and no effort has been made to address these
issues. Hence my proposal to work on the packages if they were
orphaned. Although I could teach Thomas or someone else how and
why this should be done, I don't have that kind of time right
now. Working on the package is less time consuming.
Loic, I really don't see why I should orphan a package just because you
believe it doesn't have the correct optimization. If you look at the
Debian bug tracker, you will see that I am very reactive to any issue,
and that I do apply patches which are sent against the packages I
maintain. So far, I haven't seen any patch from you sent against these
libraries.

At the same time as you're asking for orphaning a package which is well
maintained, you are saying "I don't have that kind of time right now".

Please have a more positive and constructive attitude. Get a patch done,
send it upstream to fix the issue, and then we can go from there. Unless
this is done, I think it's really a bad attitude to ask for the package
to be orphaned, or to ask to take it over.

Cheers,

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loic Dachary
2015-07-09 21:48:32 UTC
Permalink
Hi Thomas,

I'm offering my help, this is positive :-) I'm sure you're very reactive in maintaining the package, no question about it. My offer relates to solving data integrity potential problems, integration testing as well as code optimization. It so happens that I don't have time to do team work on this, hence my proposal to take over if the package was orphaned.

I acknowledge this is not an option for you, no worries.

Cheers
Post by Thomas Goirand
Post by Loic Dachary
Post by Dmitry Smirnov
Post by Loic Dachary
The other reason is that
jerasure can be optimized for SIMD instructions (ARM / INTEL) and not
doing so significantly impacts performances.
Once again, this seems to be an improvement suggestion for libjerasure rather
than argument against using system library.
I'm not saying it's impossible. Jerasure has been packaged for
quite some time now and no effort has been made to address these
issues. Hence my proposal to work on the packages if they were
orphaned. Although I could teach Thomas or someone else how and
why this should be done, I don't have that kind of time right
now. Working on the package is less time consuming.
Loic, I really don't see why I should orphan a package just because you
believe it doesn't have the correct optimization. If you look at the
Debian bug tracker, you will see that I am very reactive to any issue,
and that I do apply patches which are sent against the packages I
maintain. So far, I haven't seen any patch from you sent against these
libraries.
At the same time as you're asking for orphaning a package which is well
maintained, you are saying "I don't have that kind of time right now".
Please have a more positive and constructive attitude. Get a patch done,
send it upstream to fix the issue, and then we can go from there. Unless
this is done, I think it's really a bad attitude to ask for the package
to be orphaned, or to ask to take it over.
Cheers,
Thomas Goirand (zigo)
--
Loïc Dachary, Artisan Logiciel Libre
Dmitry Smirnov
2015-07-10 22:35:23 UTC
Permalink
Post by Loic Dachary
It so happens that I don't have time to do team work on
this, hence my proposal to take over if the package was orphaned.
No time for team work?!? Please enlighten us about your plans to fix
everything single-handedly as soon as those pesky co-maintainers are out of
your way. I wonder why Debian people bother to collaborate in teams if
working alone is so much more productive and easier?
--
Regards,
Dmitry Smirnov.

---
Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken
Loic Dachary
2015-07-11 07:33:06 UTC
Permalink
Hi Dmitry,
Post by Dmitry Smirnov
Post by Loic Dachary
It so happens that I don't have time to do team work on
this, hence my proposal to take over if the package was orphaned.
No time for team work?!? Please enlighten us about your plans to fix
everything single-handedly as soon as those pesky co-maintainers are out of
your way. I wonder why Debian people bother to collaborate in teams if
working alone is so much more productive and easier?
:-) I suppose I would have reacted the same way as you just did if in your position. Team work is key to everything and my words did not convey what I meant, please excuse me. Being French, I sometime get lost in translation.

We're doing a lot of work in Ceph, currently, to simplify integration testing. It is unfortunately still quite complex to setup and at the same time critical to ensure non regression and data integrity. I would be very happy to share what I've learnt over the past two years with co-maintainers, but that would take time. It would also take time to get access, learn how to schedule tests and analyze results. Instead I'm working to simplify the usage of the integration test infrastructure (see http://tracker.ceph.com/issues/6502 for instance) and I hope it can be easily applied independently to other projects such as jerasure, maybe some time next year.

While it would be perfectly OK to wait a year or two for that to happen, in the case of jerasure this risk of data loss (and also the lack of optimized versions of the library) prompted me to offer my help as a solo maintainer of jerasure. Thomas also worked solo so far and did not communicate upstream, I figured such a switch would not break a team dynamic or a productive dialog between the maintainer and the upstream.

Ceph is not using the jerasure library packaged in Debian GNU/Linux, I'm not directly concerned by the state of the package. But I care for jerasure beyond Ceph. However Thomas turned down my offer and the discussion is over.

Cheers
--
Loïc Dachary, Artisan Logiciel Libre
Dmitry Smirnov
2015-07-11 07:47:23 UTC
Permalink
Hi Loic,
Post by Loic Dachary
:-) I suppose I would have reacted the same way as you just did if in your
:position. Team work is key to everything and my words did not convey what
:I meant, please excuse me. Being French, I sometime get lost in
:translation.
Thank you for understanding and clarification. Your first reply did sound
strange but it was your second reply (where you seemingly confirmed the same
thing) that triggered my answer...
Post by Loic Dachary
We're doing a lot of work in Ceph, currently, to simplify integration
testing. It is unfortunately still quite complex to setup and at the same
time critical to ensure non regression and data integrity. I would be very
happy to share what I've learnt over the past two years with
co-maintainers, but that would take time. It would also take time to get
access, learn how to schedule tests and analyze results. Instead I'm
working to simplify the usage of the integration test infrastructure (see
http://tracker.ceph.com/issues/6502 for instance) and I hope it can be
easily applied independently to other projects such as jerasure, maybe
some time next year.
Interesting. :)
Post by Loic Dachary
While it would be perfectly OK to wait a year or two for that to happen, in
the case of jerasure this risk of data loss (and also the lack of
optimized versions of the library) prompted me to offer my help as a solo
maintainer of jerasure. Thomas also worked solo so far and did not
communicate upstream, I figured such a switch would not break a team
dynamic or a productive dialog between the maintainer and the upstream.
Ceph is not using the jerasure library packaged in Debian GNU/Linux, I'm
not directly concerned by the state of the package. But I care for
jerasure beyond Ceph. However Thomas turned down my offer and the
discussion is over.
I think it was a mistake to present "offer" in a way like if Thomas were a
problem or obstacle. I understand what it takes to sponsor beginners'
packages and how much time and patience it involves to discuss all the
issues. However Thomas is a skilled developer like yourself. Throw some code
at him -- he can speak that language. ;)
It is a mistake to act in anticipation of problems with cooperation before
they happen (if they ever going to happen). And since you acted like Thomas
can't cooperate with you at the same level it created potential for self-
fulfilling prophecy...
I hope it makes sense.
--
All the best,
Dmitry Smirnov

---

A creative man is motivated by the desire to achieve, not by the desire
to beat others.
-- Ayn Rand
Thomas Goirand
2015-07-13 15:52:44 UTC
Permalink
Post by Dmitry Smirnov
Post by Loic Dachary
It so happens that I don't have time to do team work on
this, hence my proposal to take over if the package was orphaned.
No time for team work?!? Please enlighten us about your plans to fix
everything single-handedly as soon as those pesky co-maintainers are out of
your way. I wonder why Debian people bother to collaborate in teams if
working alone is so much more productive and easier?
+1 here, I wouldn't have say it better.

Also, if I knew for sure that you'd do a perfect work on maintaining
these packages alone, I probably would have accept. But I do remember I
had to ping you 5 or 6 times to get a RC fixed when you maintained stuff
for OpenStack, so I don't want this to happen again. The fact that you
are upstream for part of the thing is also another reason *against*
giving you the package.

Cheers,

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
James Page
2015-07-08 15:52:11 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by Dmitry Smirnov
Post by Loic Dachary
Without integration tests, linking Ceph against the wrong
jerasure version may lead to data loss. Prior to publishing a
Ceph version, various integration tests run to verify encoding
/ decoding,
Those check are part of post-build tests, right?
While I was maintaining Ceph I've made changes to run unit tests
but James reverted it as well. :(
Not sure I can take credit for that


- --
James Page
Ubuntu and Debian Developer
***@ubuntu.com
***@debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVnUcrAAoJEL/srsug59jDILAQAMf+um/R0guxNg3uOwnTFPtL
fkrgHrDVP3xtm6NHr7uSM0RKEV0QW0kPmpRfz7SKbSWXaqE2ZpllA4isQgI5zJUL
ry9Bv5peYVV2tJHIx9CXmLrPpAQXV3q5BbglcGdozSK0BCbv9ER1Cv2UmREEzEzA
6wbCg7+B82OHx9VNwu2fWXmUbkkpVe9bzyu4BTiZEfI5VR5EvYz/Oc/iYsebfWxB
Goo0TIXbgxBgmtUgdZHgB3sHEAKJQh67hX4T7upikzuNO6eHpWXAOZI0jrPZCQhb
syh+fXEFuS+XOp3LS0co9QkLOqfjzyjzt//l3JvPnYBl4iA0zXjqPvBfH7+PTu81
xFAJtj2fUvYJIMr4DxMv31A/5Yddu6omGda2cJKJ0bG6u4GyVK3vP7Y7ybkGMfw7
HbXOmXa1RvwXYVbCPI+Z6cOAm9YcxXUm8e25wZN8d55fR1AELXZX+WUdEdRzRrIa
mxSQm1vfRrd3X6ZeH46kU1rfPm2VlLwVsZ2UJ/rjDXF0ggmv7Bna7HMZIKV4eKOl
AToZL81xQGQxs0QLIKq+RhOS+y4ldJ6093QYNYtcC/uoFGasAN9naxc3RVlJYe9Y
VgtzkwpVZKbF3pKUhn7c0tS23Ckiwopk31C+JP3AGlzLh+2jP1ovMARL0tl7QiJW
IxzIfHAKwQodP9k0KuOt
=koO2
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Dmitry Smirnov
2015-07-08 23:42:34 UTC
Permalink
Post by James Page
Post by Dmitry Smirnov
While I was maintaining Ceph I've made changes to run unit tests
but James reverted it as well. :(
Not sure I can take credit for that
Well, the evidence is right there:

https://anonscm.debian.org/cgit/pkg-ceph/ceph.git/commit/?h=experimental&id=616b6dab
--
Best wishes,
Dmitry Smirnov.

---

Without doubt you are not sane.
-- Tage Danielsson
Thomas Goirand
2015-07-09 21:19:18 UTC
Permalink
Post by Dmitry Smirnov
Post by Loic Dachary
Without integration tests, linking Ceph against the wrong jerasure version
may lead to data loss. Prior to publishing a Ceph version, various
integration tests run to verify encoding / decoding,
Those check are part of post-build tests, right?
While I was maintaining Ceph I've made changes to run unit tests but James
reverted it as well. :(
Post by Loic Dachary
this is the main incentive to have jerasure as part of Ceph.
I'm sure Thomas can enable optimisations in jerasure library.
Unfortunately, no, I can't, because not all amd64 procs have SSE
feature, and we need the package to work on every amd64 machines.
Post by Dmitry Smirnov
Post by Loic Dachary
The other reason is that
jerasure can be optimized for SIMD instructions (ARM / INTEL) and not
doing so significantly impacts performances.
Once again, this seems to be an improvement suggestion for libjerasure rather
than argument against using system library.
Agreed.

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Continue reading on narkive:
Loading...