While we're at it, #include LogEvent.h from each of
the log events, some of which didn't include it previously!
Signed-off-by: Greg Farnum <greg@inktank.com>
If we get EAGAIN from a paxos restart/election/whatever, we should
restart the message instead of just blindly acking it.
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Luis <joao.luis@inktank.com>
We can get ECANCELED, EAGAIN, or success out of the completion contexts,
but in the EAGAIN case (meaning there was an election) we were sending
a success to the client. This resulted in client hangs and all-around
confusion when the monitor cluster was thrashing.
Backport: bobtail
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Luis <joao.luis@inktank.com>
Fixes: #2941
Instead of iterating through the parts one by one when reading
an object, we can now send multiple requests in parallel. Two new
configurables added to control the max request size, and the total
size of pending requests.
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
Support the bucket-owner-read and bucket-owner-full
canned acls.
Signed-off-by caleb miles <caleb.miles@inktank.com>
Reviewed-by: Yehuda Sadeh <yehuda@inktank.com>
We may not have "created" the temp collection since OSD restart
before removing the PG. have_temp_coll must also look at the
OSD store. Currently, the only user is pg removal, so the
extra work is acceptable.
Backport: bobtail
Signed-off-by: Samuel Just <sam.just@inktank.com>
This fixes bad entries in user's bucket list that may have occured
due to issue #4039. Syntax:
$ radosgw-admin user check --uid=<uid> [--fix]
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
(cherry picked from commit 9cb6c33f0e)
Conflicts:
src/rgw/rgw_admin.cc
Fixes: #4039
User's list of buckets is getting modified even if bucket already
exists. This fix removes the newly created directory object, and
makes sure that user info's data points at the correct bucket.
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
(cherry picked from commit 9d006ec40c)
Conflicts:
src/rgw/rgw_op.cc
src/rgw/rgw_rados.cc
apparently it was once known as set_config. Fix up everything to
refer to the new name. Also, fix up the help message.
Signed-off-by: Dan Mick <dan.mick@inktank.com>
We need to make sure the pg epoch is persisted during
activate_map.
Backport: bobtail
Reviewed-by: Sage Weil <sage@inktank.com>
Signed-off-by: Samuel Just <sam.just@inktank.com>
Sage pointed out we should try for consistent naming on these debug
options, and this option is like our other inject_[x] stuff.
While we're here, make the config option comment a bit clearer.
08b82b3ef6
If the osd itself is behind on many maps during boot, it will get more and
(as part of that) flush the peering wq to ensure the pgs consume them.
However, it is possible for OSD to have latest/recnet maps, but pgs to be
behind, and to jump directly to boot and join. The OSD is then laggy and
unresponsive because the peering wq is way behind.
To avoid this, call consume_map() (kick the peering wq) at the end of
init and flush it to ensure we are *internally* all caught up before we
consider joining the cluster.
I'm pretty sure this is the root cause of #3905 and possibly #3995.
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Samuel Just <sam.just@inktank.com>
We missed a shortcut return from _flush() when doing
e9a6694d01, so _fsync() calls
were failing. To fix, if _flush discovers there's nothing to flush,
trigger the completion by calling onfinish->finish().
Fixes#4038
Signed-off-by: Greg Farnum <greg@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
This option specifies (in the range 0-1) the percentage of modifying
operations that should be responded to without including a trace
for the dentries.
In order to implement it, we add a "modify" parameter to
set_trace_dist(), and the callers fill that with
mdr->req->may_write().
Signed-off-by: Greg Farnum <greg@inktank.com>
Reviewed-by: Sam Lang <sam.lang@inktank.com>
