There was a silent bug in the activate 'acks' that go from the replica back
to the primary. Prior to 86aa07d7a9, we
were passing same_interval_since to the callback, which mean that
sometimes _activate_committed() would ignore it and we wouldn't update
last_epoch_started. This was mosty invisible; the next peering event would
just, in some cases, look at more past intervals than it needed to.
In 86aa07d7a9 we fixed this so that the check
is correct. (We noticed because now we aren't setting the pg CLEAN flag
until after last_epoch_started is updated.) That, in turn, revealed a
similar bug that we're fixing here: the replica's last_peering_reset could
be lower than the primary's, such that the activate 'ack' info is ignored.
To fix this, simply set last_peering_reset to the current epoch when the
replica activates; this will always be greater than the primary's.
Signed-off-by: Sage Weil <sage@inktank.com>
The various rgw tools were all recompiling my_libradosgw_src files over
again. Instead build a single .a (not .la!) and link that in.
Signed-off-by: Sage Weil <sage@inktank.com>
Do not mark a PG CLEAN or set last_epoch_clean until after the PG activate
is stable on all replicas.
This effectively means that last_epoch_clean will never fall in an interval
that follows last_epoch_started's interval. It *can* be >
last_epoch_started when it falls within the same interval.
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
We are checking against last_peering_reset in _activate_committed(), so we
need to pass in that value to compare against; last_peering_reset may be
greater than same_interval_since, e.g. on a replica that learns about the
PG after the initial creation epoch.
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
- always include 'slow request' in the warning string
- only summarize if we warn about anything (they all may have backed off)
- be more concise
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
int is 32-bit on 64-bit archs, but ssize_t is 64-bits. This fixes overflow
when reading large (>2GB) extends.
Fixes: #2275
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
This avoids confusion for the user who isn't sure if they should wait for
complete or safe on a read aio. It also means that you can always wait
for safe for both reads or writes, which can simplify some code.
Dup the roundtrip functional tests to verify this works.
Signed-off-by: Sage Weil <sage@newdream.net>
Reviewed-by: Yehuda Sadeh <yehuda.sadeh@inktank.com>
If you give it a nonsensical loc, it will fail check_item_loc() (false) and
then error out on insert_item().
Reported-by: Sam Just <sam.just@inktank.com>
Signed-off-by: Sage Weil <sage@newdream.net>
We don't adjust the internal hierarchy structure (currently). This is a
bit confusing, so describe the semantics in some detail.
Signed-off-by: Sage Weil <sage@newdream.net>
- drop useless cur for check_item_loc
- comment the checks we're doing so the code is understandable
- use name_exists instead of broken get_item_id != 0 check
Signed-off-by: Sage Weil <sage@newdream.net>
This looks in /proc to count threads. Kludgey and no longer needed.
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
We were verifying that there was only 1 thread (the presumably main()) when
we call daemonize. However, with the new logging code, we stop a thread
right before the check, and /proc apparently updates asynchronously such
that our attempt to count running threads gives us a bad answer.
Just remove this kludgey check; we'll have to catch this class of bugs
the hard way.
Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
This fixes issue #2381.
The method interface was different than the one needed in order
to override the one in RGWRados.
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
