hmm, everytime modify any file, then compile, then wait&wait&wait, so trying to optimize
this part, wish to decrease header dependency, try to improve compile speed.
Signed-off-by: Xiaowei Chen <chen.xiaowei@h3c.com>
submit_transaction takes ownership of the transaction implicitely. Make
this implicit using an rvalue ref to force usage of std::move and move
constructor.
Signed-off-by: Samuel Just <sjust@redhat.com>
Use explicit keyword for constructors with one argument to
prevent implicit usage as conversion functions.
Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
Extend the PGBackend::objects_read_async interface to support *fast read*,
add the implemenation for ECBackend, in which we issue redundant reads,
and use the first returned (to decode) to serve clients.
Signed-off-by: Guang Yang <yguang@yahoo-inc.com>
The temp objects have distinct pool ids. Old temp objects are already
blown away on OSD restart. This patch removes all the futzing with
temp_coll and puts the temp objects in the same collection as everything
else.
Interesting, collection_move_rename is now always using the same source
and dest collection. Hmm!
Signed-off-by: Sage Weil <sage@redhat.com>
Sometime after 1.55, boost introduced a forward declaration of
operator<< in optional.hpp. In 1.55 and earlier, when << was used
without the _io having been included, what got dumped was an implicit
bool conversion.
http://tracker.ceph.com/issues/10688 Refs: #10688
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
0 is a weak initial value for a CRC since it doesn't change with a sequence
of 0 bytes (which are relatively common). -1 is better. Use -1 when
everyone in the acting set supports it.
Signed-off-by: Sage Weil <sage@redhat.com>
ECRecPred assumes recovering any number of chunk is possible as long as
at least K chunks are available. It builds the want() set accordingly in
the constructor and arbitrarily set the first K chunks. But it would be
the same if it set the last K chunks.
While this is correct for jerasure and isa plugins, it is not true in
general. The predicate should assume that all chunks are going to be
recovered and return true if they can all be recovered. Otherwise, the
following can happen:
* a PG has chunks 0,1,2,3 for K=2, M=2
* ECRecPred is initialized a set want to 0,1 because K=2
* ECRecPred claims the plugin can recover when provided 0,1
* the plugin is then required to recover 0,1 using 2,3 and fails
This can happen for the LRC plugin with k=4,m=2,l=3 which is
01234567
DDc_DDc_
DDDc____
____DDDc
and if chunks 0,1,2,3 are missing there is no way to recover chunks
4,5,6,7.
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
The generic portion of on_change() cleaned up temporary on-disk objects
and requires a Transaction. The rest is clearing out in-memory state and
does not. Separate the two.
Signed-off-by: Sage Weil <sage@inktank.com>
We simply trim the roll back info up to min_last_complete_ondisk
since we cannot correctly rollback past that point anyway!
ReplicatedPG
-> PGBackend::submit_transaction
-> Backend messages
-> PGBackend::Listener::log_operation
-> append_log
Signed-off-by: Samuel Just <sam.just@inktank.com>
We don't actually send the whole info on each repop, just the log
entries, updated stats, and a few other bits. For hit_set ops, we need
to also communicate the new hit_set history status atomically with the
log entries and the transaction. Thus, we add a channel for an optional
pg_hit_set_history_t field in PGBackend::submit_transaction interface
and associated messages and implementations to update the hit_set info
field along with the log entries.
This also means that hit_set_(persist|trim) update an
updated_hit_set_history field on the OpContext instead of directly
modifying the info field.
Fixes: #8124
Signed-off-by: Samuel Just <sam.just@inktank.com>
