A couple firefly point releases ago we removed the Ceph requirement that, when EC pools are present, all clients must have the EC feature bit. This is because the only users of EC are current not kernel based, so even having that feature bit doesn't mean a newer kernel is any better off than an older one. And (we thought) it meant that an older kernel (e.g., 3.12) can still map an rbd or mount cephfs when the cluster has a new EC pool created for unrelated purposes. ...but there is still a problem. The EC pools need new CRUSH rule steps to work effectively, and normally have a rule using those new features for the EC pool. And the code that ensures that clients understand all features that the CRUSH map uses works, so those kernels *still* can't talk to a firefly cluster with EC pools (if the EC pools are configured properly and are using a "good" CRUSH rule). Simply not requiring that feature of any client is problematic because clients using those pools do need to understand that feature. So, I'm not sure what the quick fix is... As for the real fix, I think we need to add a features field to the OSDMap pg_pool_t so that, for a given pool, there may be additional client requirements. The CRUSH feature code can then map the per-rule feature bits to only the pools that need it. And eventually clients can be made to verify those per-pool features. I suppose we could then backport all of that to firefly? :/ sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
