It doesn't actually interfere with publish_lock, and the current osdmap
ref.
Document what is going on.
Always preceed publish_map() with one or more pre_publish_map() calls.
Signed-off-by: Sage Weil <sage@inktank.com>
Note that if we don't get a con our behavior largely does not matter, since
we know we are about to get a Reset event anyway.
Signed-off-by: Sage Weil <sage@inktank.com>
Use the OSDService helper to send messages to peers. This ensures that if
we are on an older OSDMap the messages don't actually get sent to down
OSDs that handle_osd_map has done mark_down() on.
Signed-off-by: Sage Weil <sage@inktank.com>
Way back in 4b3bb5ab37 we changed this to
pass an entity_inst_t down to fix a race. The refactor of the PG map
handling made this unnecessary; remove it. The PG's OSDMap is not coherent
with respect to the PG when we take the lock, which is all that is
needed here.
Signed-off-by: Sage Weil <sage@inktank.com>
There is a race between handle_osd_map -> note_down_osd() and PG threads:
- handle_osd_map -> note_down_osd marks down an osd for epoch N
- a pg thread with epoch <N sends a message to the (old) peer, reopening
the msgr connection
- nobody cleans up
Introduce a pre_publish_map() OSDService method and helpers for sending
messages to peers. Pass in the epoch we are working from, and drop the
message on the floor if the target OSD has been since marked down.
See #3548.
Signed-off-by: Sage Weil <sage@inktank.com>
This adds a bash script that creates an rbd image, then repeatedly
maps and unmaps it for a specified duration (5 minutes by default).
Signed-off-by: Alex Elder <elder@inktank.com>
Make import work; do I/O in image native block size.
Note: creating sparse images is not currently attempted; could
scan for runs of zeros and write discontiguous chunks to image.
Fixes: #3503
Signed-off-by: Dan Mick <dan.mick@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
(cherry picked from commit c99d9c3ae7)
Detect a misordered ondisk tmap... if we are already decoding it. We still
leave the trailing bits unchecked.
Signed-off-by: Sage Weil <sage@inktank.com>
The MDS may include RM ops in a tmap update for items that were already
removed: after restarting and replaying the journal, it doesn't know
which dentries were previously committed and which were not.
No other (known) users care about the error code.
Signed-off-by: Sage Weil <sage@inktank.com>
The previous tmap implementation requires that the update stream be
sorted or else it will behave erratically (by placing new keys in the
map out of order). This can cause very strange failures: reads may
appear to return the correct result initially, but once intervening
keys are remove they will not... depending on how read is implemented
on the client side.
Fix this by doing the optimized updates initially, but falling back to
a slow implementation if an unsorted update is detected. It is slow,
but such updates are rare.
Signed-off-by: Sage Weil <sage@inktank.com>
Validate change to not assume dest pool == src pool
Signed-off-by: Dan Mick <dan.mick@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
(cherry picked from commit 39180430b9)
import allows specifying one image, implicitly or explicitly the
"source" image, even though it's really the destination. Fix up
the reassignment of 'source' to 'dest', and check for and complain
about specifying two different pools or images for import.
Signed-off-by: Dan Mick <dan.mick@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
(cherry picked from commit c219698149)
Don't default destpool to srcpool; it's surprising, and
not useful/helpful enough to violate the convention that
"default pool is rbd"
Signed-off-by: Dan Mick <dan.mick@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
(cherry picked from commit 3b0c360528)
User-space tool that interacts with the monitor, with the objective of
generating a workload mimicking a set of OSDs and clients.
As it is, the tool will mimic any number of OSDs, by keeping in-memory
stubs that will act as independent OSDs, generating random operations
that will induce map updates; the client stub, on the other hand,
performs no operations besides connecting to the monitor and whatever
happens between the Objecter class and the monitor (mainly keeping
updated with map updates).
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
Before we only allowed buckets (say, 'root') to be defined *before*
rules.
With this patch, we allow buckets and rules to be defined by any order,
although some care should be taken when creating the plain-text crush
map, or the crushtool will error out when a rule uses a bucket only
defined later on in the file.
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
'verbose' was a bool that would either be passed as one or zero to class
CrushCompile. However, most messages would only be outputted with a
verbose level > 1.
This patch makes it so that multiple '-v' increase the verbosity level;
i.e., -v mean verbose = 1; -v -v means verbose = 2; and so forth.
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
If the call to syncfs() fails, don't try to call syncfs again via
syscall(). If HAVE_SYS_SYNCFS is defined, don't fall through to try
syscall() with SYS_syncfs or __NR_syncfs.
Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
There is message ordering race in cephfs kernel client. We compose
cap messages when i_ceph_lock is hold. But when adding messages
to the output queue, the kernel releases i_ceph_lock and acquires
a mutex. So it is possible that cap messages are send out of order.
If the kernel client send a cap update, then send a cap release,
but the two messages reach MDS out of order. The update message
will re-add the released caps. This patch adds code to check if
caps were actually issued when confirming cap receipt.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
