Am 15.10.2014 14:11, schrieb Ric Wheeler: > On 10/15/2014 08:43 AM, Amon Ott wrote: >> Am 14.10.2014 16:23, schrieb Sage Weil: >>> On Tue, 14 Oct 2014, Amon Ott wrote: >>>> Am 13.10.2014 20:16, schrieb Sage Weil: >>>>> We've been doing a lot of work on CephFS over the past few months. >>>>> This >>>>> is an update on the current state of things as of Giant. >>>> ... >>>>> * Either the kernel client (kernel 3.17 or later) or userspace >>>>> (ceph-fuse >>>>> or libcephfs) clients are in good working order. >>>> Thanks for all the work and specially for concentrating on CephFS! We >>>> have been watching and testing for years by now and really hope to >>>> change our Clusters to CephFS soon. >>>> >>>> For kernel maintenance reasons, we only want to run longterm stable >>>> kernels. And for performance reasons and because of severe known >>>> problems we want to avoid Fuse. How good are our chances of a stable >>>> system with the kernel client in the latest longterm kernel 3.14? Will >>>> there be further bugfixes or feature backports? >>> There are important bug fixes missing from 3.14. IIRC, the EC, cache >>> tiering, and firefly CRUSH changes aren't there yet either (they >>> landed in >>> 3.15), and that is not appropriate for a stable series. >>> >>> They can be backported, but no commitment yet on that :) >> If the bugfixes are easily identified in one of your Ceph git branches, >> I would even try to backport them myself. Still, I would rather see >> someone from the Ceph team with deeper knowledge of the code port them. >> >> IMHO, it would be good for Ceph to have stable support in at least the >> latest longterm kernel. No need for new features, but bugfixes should be >> there. >> >> Amon Ott > > Long term support and aggressive, tedious backports are what you go to > distro vendors for normally - I don't think that it is generally a good > practice to continually backport anything to stable series kernels that > is not a bugfix/security issue (or else, the stable branches rapidly > just a stale version of the upstream tip :)).
bugfix/security is exactly what I am looking for. Amon Ott -- Dr. Amon Ott m-privacy GmbH Tel: +49 30 24342334 Werner-Voß-Damm 62 Fax: +49 30 99296856 12101 Berlin http://www.m-privacy.de Amtsgericht Charlottenburg, HRB 84946 Geschäftsführer: Dipl.-Kfm. Holger Maczkowsky, Roman Maczkowsky GnuPG-Key-ID: 0x2DD3A649 -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
