adjust_item_weight method will adjust all buckets which the item
inside. If the osd.0 in host=fake01 and host=fake02, we execute
"ceph osd crush osd.0 10 host=fake01", it not only will adjust fake01's
weight, but also will adjust fake02's weight.
the patch add adjust_item_weightf_in_loc method and fix remove_item,
_remove_item_under, update_item, insert_item, detach_bucket methods.
Signed-off-by: Rongze Zhu <zrzhit@gmail.com>
A short introduction to the first time user of an erasure coded pool.
It includes a reminder of how it relates to cache tiering and links to
define new profiles with an example.
There was examples in the developer documentation but the operator
expects to find such a guide in the rados operations chapter.
http://tracker.ceph.com/issues/9970Fixes: #9970
Signed-off-by: Loic Dachary <ldachary@redhat.com>
When killing a daemon, instead of using kill -9 to check the process was
terminated, use kill -0. Should the pid of the process be reused
immediately after, it would be wrong to kill the new process. Worst case
scenario the kill_daemon function returns before the process is
confirmed to be killed but this is not treated as an error and is
unlikely to cause any problem.
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
So that it can be used instead of stop.sh to stop vstart.sh daemons. The
problem with stop.sh is that it kills any daemon, not just a selection.
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
Three scripts are added to run qa/workunits/cephtool/test.sh for each
daemon (mon, mds, osd) so they can be run in parallel.
http://tracker.ceph.com/issues/9815Fixes: #9815
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
Listing tests to be run in a single script does not take advantage of
parallel runs in make.
The vstart_wrapper.sh script is reworked and made less specialized and
let the caller decide which daemons to run via CEPH_START and does not
enforce the number of deamons of each time. It no longer uses stop.sh to
avoid killing the osd/mon/mds that are unrelated to the tests.
http://tracker.ceph.com/issues/9815Fixes: #9815
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
Run the mon on each test on a different port so they can run in
parallel.
http://tracker.ceph.com/issues/9815Fixes: #9815
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
All cleanup is now routed through respond_to_request(),
which invokes the internal_op_finish Context*, then does
mdcache->request_finish(). This is easier to reason about,
and indeed fixes a bug (I was not cleaning up locks
following flush). Use the MDSContinuation to facilitate
this in scrub's case.
Signed-off-by: Greg Farnum <gfarnum@redhat.com>
Rather than assuming that any necessary inodes are in the cache, split up
MDCache::scrub_dentry into setup and work phases. Add an internal_op_finisher()
to MDRequest. Dispatch any CEPH_MDS_OP_VALIDATE internal operations to
scrub_dentry_work(). Taken together, these make everything work properly when
path_traverse() (by way of rdlock_path_pin_ref()) needs to go to disk before
satisfying the lookup.
Signed-off-by: Greg Farnum <greg@inktank.com>
For now, just return -EXDEV ("Cross-device link") on internal ops that
require forwarding, as forwarding internal ops will require a great deal more
infrastructure.. But push the issue down to this level instead of worrying
about it in path_traverse, and consider the possibility that the MDRequest
might not have a client_request that it's wrapped around.
Signed-off-by: Greg Farnum <greg@inktank.com>
The generic reply_request(MDRequest, int) is now the only caller. It's still
just building an MClientRequest to pass along, but we can change it a lot more
easily now to support responding to non-client requests.
Signed-off-by: Greg Farnum <greg@inktank.com>
Set the MClientReply::extra_bl from reply_extra_bl unconditionally in
reply_request(), instead of only in early_reply(). Further isolate
the reply_request() callers from the use of MClientReply this way.
Signed-off-by: Greg Farnum <greg@inktank.com>
We have members for these two parameters in the MDRequestImpl already, so
make use of them. This helps us move towards dropping the expectation of an
MClientRequest from functions like rdlock_path_pin_ref().
Signed-off-by: Greg Farnum <greg@inktank.com>
scrub_dentry() is passed a string path, and it validates it before replying. We
hook up an admin socket command "scrub_path" to call it and dump the output.
Signed-off-by: Greg Farnum <greg@inktank.com>
Add a function that will validate the on-disk state of the CInode. We currently
check that the on-disk backtrace matches (or is older) and compare rstats on
dirfrags against the parent dir's inode (for directories only).
TODO: validate that the on-disk Inode object matches what the parent
directory holds.
It's using a sort-of new programming model, trying to stuff stack data into
a Continuation object and write everything sequentially instead of having
a function and Context per IO.
Signed-off-by: Greg Farnum <greg@inktank.com>
Signed-off-by: John Spray <john.spray@redhat.com>
Unlike the regular Continuation, this one works in terms of an MDRequest
and has wrappers to provide Context callbacks that are either
internal MDS or IO appropriate.
Signed-off-by: Greg Farnum <gfarnum@redhat.com>
This way we can create duplicate CInodes without actually linking them
into the cache. It'll be helpful for comparing different versions of
disk states and in-memory state, etc.
Signed-off-by: Greg Farnum <greg@inktank.com>
Use this passthru in the Server path locking functions so that we can get
locks or auth pins without an associated MClientRequest.
Signed-off-by: Greg Farnum <greg@inktank.com>
operator== is checking equality of the version as well, but I want
something I can use to check that the internal sums match. This is useful
for eg comparing the sums of a set of dirfrags to the tally stored in
the inode.
Signed-off-by: Greg Farnum <greg@inktank.com>
This compares one inode_t against another, seeing which version is newer
and checking that differences in the data members make sense given that.
Signed-off-by: Greg Farnum <greg@inktank.com>
