On Fri, 1 Aug 2014, Ilya Dryomov wrote: > On Fri, Aug 1, 2014 at 10:06 PM, Ilya Dryomov <ilya.dryomov at inktank.com> wrote: > > On Fri, Aug 1, 2014 at 4:22 PM, Ilya Dryomov <ilya.dryomov at inktank.com> wrote: > >> On Fri, Aug 1, 2014 at 4:05 PM, Gregory Farnum <greg at inktank.com> wrote: > >>> We appear to have solved this and then immediately re-broken it by > >>> ensuring that the userspace daemons will set a new required feature > >>> bit if there are any EC rules in the OSDMap. I was going to say > >>> there's a ticket open for it, but I can't find one... > >> > >> Larry did not mention EC pools, and regardless, it returns EIO, which > >> probably means it's failing past the feature bit check. (3.2, which is > >> the kernel Larry is on, goes into retry/backoff loop if the features > >> are missing.) That said, we need to re-fix the EC problem ;) > > > > Oh, it *does* return EIO eventually, I just never waited long enough > > for it to return.. Greg, I assume you are referring to CRUSH_V2 when > > talking about "a new required feature bit if there are any EC rules in > > the OSDMap"? Yeah. > On a separate note, I'm going to have to fix the kernel client to > return something more appropriate than EIO. And retrying a few times > before saything "this is not supported" is bogus, I'll fix that too. That would be great! It will be a bit wonky to get the error up through a few layers, but we need to do it eventually... sage