New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rgw: fix handling of ENOENT in RGWRadosGetOmapKeysCR #19878
Conversation
when this operates on a nonexistent object, the osd will reject the request with ENOENT before trying to process the subops. so Objecter will get back a subop return code of 0, try to decode an empty bufferlist into the result and map that subop return code to EIO by using the AioCompletion's return code, we get the correct result of ENOENT instead Signed-off-by: Casey Bodley <cbodley@redhat.com>
Signed-off-by: Casey Bodley <cbodley@redhat.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Life gets tough, man!
{ | ||
int r = cn->completion()->get_return_value(); | ||
|
||
set_status() << "request complete; ret=" << r; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I have searched aio_operate
in RGW code to check whether there is similar problem. It seems that all async rados CR(RGWRadosSetOmapKeysCR, RGWRadosRemoveOmapKeysCR, RGWRadosRemoveCR, RGWRadosBILogTrimCR) already use cn->completion()->get_return_value()
.
maybe we should create a base class, avoid those duplicated code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should create a base class, avoid those duplicated code?
that sounds reasonable, yeah. it would help distinguish the ops that use aio_operate vs async_rados
when this operates on a nonexistent object, the osd will reject the request with ENOENT before trying to process the subops. so Objecter will get back a subop return code of 0, try to decode an empty bufferlist into the result and map that subop return code to EIO. by using the AioCompletion's return code, we get the correct result of ENOENT instead
separately, it now calls omap_get_keys2() instead of omap_get_vals2(), and uses set<string> instead of map<string, bufferlist> accordingly