Oh, in that case the peers could just share their supported ops with the primary or something (like we do with mon commands). That sounds good to me, anyway? -Greg On Thu, Sep 11, 2014 at 1:46 PM, Samuel Just <sam.just@xxxxxxxxxxx> wrote: > No, we don't put the transaction into the pg log. > -Sam > > On Thu, Sep 11, 2014 at 1:40 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: >> Does the hint not go into the pg log? Which could be retried on an older OSD? >> >> On Thu, Sep 11, 2014 at 1:33 PM, Samuel Just <sam.just@xxxxxxxxxxx> wrote: >>> That part is harmless, the transaction would be recreated for the new >>> acting set taking into account the new acting set features. It >>> doesn't have any actual affect on the contents of the object. >>> -Sam >>> >>> On Thu, Sep 11, 2014 at 1:30 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: >>>> On Thu, Sep 11, 2014 at 1:19 PM, Samuel Just <sam.just@xxxxxxxxxxx> wrote: >>>>> http://tracker.ceph.com/issues/9419 >>>>> >>>>> librbd unconditionally sends set_alloc_hint. Do we require that users >>>>> upgrade the osds first? Also, should the primary respond with >>>>> ENOTSUPP if any replicas don't support it? >>>> >>>> Something closer to the second option, I think...but then you run into >>>> the problem where maybe the PG gets moved from a set of new OSDs to a >>>> set of old ones that don't support the op. :/ I think for anything >>>> that goes to disk you need to go through a full features-in-the-osdmap >>>> process like we did for erasure coding. >>>> -Greg >>>> Software Engineer #42 @ http://inktank.com | http://ceph.com -- 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
