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>
Passing bufferlist and not const bufferlist in aio_write(). We assign
it to another object which is not const, and it doesn't work too
well.
Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net>
Apparently S3_put_object() and S3_get_object() need to
run on the same thread as S3_runall_request_context() (at least
per context). So We now call them in the workqueue thread.
Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net>
There was a bug when doing a read with multiple threads, when
one of the threads was left behind; when it returned the compared
data string might have been cluttered by newer strings that
were longer.
Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net>
This is necessary for keep-alive to be useful. Otherwise a new
connection will be created for each request.
Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net>
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>
We do three things here:
- Wait for the dirty limit to drop _after_ writing into the cache. This
means that an active thread can always provide its dirty data to the
cache for potential writing without waiting (a small win). It's also
helpful later... (see below, and next commit)
- Don't wait for other waiters. If another thread dirtying 1MB and is
waiting for it, don't wait for them too. This prevents two threads
writing 1MB at a time with a limit of 1MB from serializing: both can
dirty their 1MB and initiate a flush, and they once 1/2 of that has
flushed one of them will be allowed to proceed.
- Update the flusher to add the dirty_waiting bytes to the amount to
write so that the OPs will indeed be parallel.
Signed-off-by: Sage Weil <sage@newdream.net>
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>
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 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>
