Bug #5497
ceph features mis-reported
0%
Description
I observed some osd daemons with 32 bit ~0 as features while others have 64 bit ~0.
Associated revisions
Pipe: use uint64_t not unsigned when setting features
Fixes: #5497
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Luis <joao.luis@inktank.com>
ceph_features.h: declare all features as ULL
Otherwise, the first 32 get |'d together as ints. Then, the result
((int)-1) is sign extended to ((long long int)-1) before being |'d
with the 1LL entries. This results in ~((uint64_t)0).
Fixes: #5497
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Luis <joao.luis@inktank.com>
Elector.h: features are 64 bit
Fixes: #5497
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Luis <joao.luis@inktank.com>
Pipe: use uint64_t not unsigned when setting features
Fixes: #5497
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Luis <joao.luis@inktank.com>
(cherry picked from commit bc3e2f09f8860555d8b3b49b2eea164b4118d817)
ceph_features.h: declare all features as ULL
Otherwise, the first 32 get |'d together as ints. Then, the result
((int)-1) is sign extended to ((long long int)-1) before being |'d
with the 1LL entries. This results in ~((uint64_t)0).
Fixes: #5497
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Luis <joao.luis@inktank.com>
(cherry picked from commit 4255b5c2fb54ae40c53284b3ab700fdfc7e61748)
Elector.h: features are 64 bit
Fixes: #5497
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Luis <joao.luis@inktank.com>
(cherry picked from commit 3564e304e3f50642e4d9ff25e529d5fc60629093)
History
#1 Updated by Samuel Just over 10 years ago
- Status changed from 7 to Pending Backport
#2 Updated by Sage Weil over 10 years ago
- Status changed from Pending Backport to Resolved
- Backport deleted (
cuttlefish)
i don't think we need to backport this.. the mons have a protocol version change and can't talk from cuttlefish -> 0.65+ anyway.
#3 Updated by Greg Farnum over 10 years ago
What was the mon protocol change covering (I missed it going in), and don't we need to preserve compatibility across the OSDs regardless of what the monitors are doing?
#4 Updated by Sage Weil over 10 years ago
the new command syntax (json instead of vector<string), and new MonCap encoding. the old protocol won't ever see a >32bit protocol feature bit. unless we backport something weird to cuttlefish...
#5 Updated by Greg Farnum over 10 years ago
I'm pretty sure that a pre-fix OSD is going to report that it supports all features to a post-fix OSD — right? That's going to cause issues for stuff like the combined object recovery.