...so that we wait until everyone who was waiting for the first
wait_for_safe has run their completion before we proceed, thus
avoiding the possibility that those completions will execute
during our trimming and cause problems.
Fixes: #10368
Signed-off-by: John Spray <john.spray@redhat.com>
This code path wasn't touched until the change
in "mds/Server: fix stray reintegration". Now we
see that it will crash in fsstress in some circumstances
when the client is doing a link operation, where
we are checking the projected linkage on the DN
before going into this function, but not the projected
parenthood of the inode.
Signed-off-by: John Spray <john.spray@redhat.com>
Pull out the stray-handling code into a separate StrayManager
class.
There is an additional improvement to stray reintegration here,
by passing the DN that triggered the reintegration through,
we should make a better choice about *which* hardlink to
reintegrate the inode into, rather than just picking the first.
Fixes: #10390
Signed-off-by: John Spray <john.spray@redhat.com>
These are to be respected by the MDS in the number
of concurrent RADOS delete operations and
number of files to be purged at once.
Signed-off-by: John Spray <john.spray@redhat.com>
Previously this was simply hardcoded to do up to
10 RADOS delete ops at a time. Make this a config
option so that Filer consumers (like the MDS) can
know how many concurrent operations will be done
on their behalf.
Signed-off-by: John Spray <john.spray@redhat.com>
This happens because when handling an MCacheExpire,
we expire inodes first and then dentries, so when
the inodes are put() their dentries still are replicated
so eval_stray fails. Do an explicit call to maybe_eval_stray
when handling the expire for the dentry in order to catch
this.
One hits this path when migrating a stray away from
a stopping MDS rank.
Signed-off-by: John Spray <john.spray@redhat.com>
This was checking tracei's primary parent DN for remoteness
as a condition to calling eval_remote. However, the *primary*
parent DN in this case is the stray, which is not remote.
The correct check is tracedn (the remote dentry that got us here)
rather than tracei->get_parent_dn() (the primary dentry for the
inode that we have looked up).
This leads to eval_remote being invoked, and reintegration
of stray hard-linked inodes working.
Signed-off-by: John Spray <john.spray@redhat.com>
There was a bug in the arguments used by the splice function to move elements from the LRU list to the head of the list.
To simplify the implementation the direction of the LRU list has been changed e.g. newest entries are pushed in front.
Signed-off-by: Andreas-Joachim Peters <andreas.joachim.peters@cern.ch>
* asphyxiate needs more toolings, see
https://github.com/ceph/asphyxiate/issues/1
* this commit basically reverts c96064
* use `autodoxygen` directive to doxygen referenced source files
* do not call `doxygen` explicitly in `build-doc`, `autodoxygen`
will take care of it.
Fixes: #6115Fixes: #6115
Signed-off-by: Kefu Chai <kchai@redhat.com>
make sure the main thread/process not release the file lock before
workers execute the operation that supposes to return EWOULDBLOCK.
Signed-off-by: Yan, Zheng <zyan@redhat.com>
In the threesome test cases, the main thread/process call PING_WORKER()
twice at each synchronization point. It's possible that one worker gets
both notifications and takes two steps forward, another worker gets no
notification.
The fix is use seperate semaphores for odd/even number synchronization
points.
Signed-off-by: Yan, Zheng <zyan@redhat.com>
Don't forget set cachemode.
By the way, For test max_target_bytes, don't reply on /etc/passwd
because different host have different size of /etc/passwd.
Avoid met this bug, i create a tmp file.
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
Using this field record the pg_poo_t::last_force_op_resend to avoid op
endless when osd reply with redirect.
Fixes: #11026
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
Signed-off-by: Sage Weil <sage@redhat.com>
If we have a mixed cluster of hammer and pre-hammer OSDs, we will fall back
to using 0 as the initial crc32c value. However, if the primary has a
stored digest, it currently compares its value to the reported value (w/
the wrong initial value) and complains.
There are two possible fixes:
- avoid storing a digest if all peers don't support it, or
- avoid complaining on scrub if all peers don't support it.
The latter is easier, and this fix also has the benefit of fixing the bug
even for clusters where this has already happened.
Fixes: #11102
Signed-off-by: Sage Weil <sage@redhat.com>
Retains old text format output when user specifies
a filename, else returns JSON. JSON output will
cope less well with large caches, but will be more
useful for automated tests.
Signed-off-by: John Spray <john.spray@redhat.com>
