Jason Dillaman [Wed, 6 Apr 2016 20:08:15 +0000 (16:08 -0400)]
rbd-mirror: workaround for intermingled lockdep singletons
If librados constructs the CephContext, lockdep will be initialized
in both the librados shared address space and also within the app
address space. This breaks lockdep's functionality and results in
a crash upon shutdown.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Jason Dillaman [Wed, 6 Apr 2016 21:18:33 +0000 (17:18 -0400)]
journal: Future does not require metadata shared pointer
Avoid keeping the metadata object alive through the lifespan of the
future. Callers can expect to receive a re-entrant callback if the
future is already safe and flush/wait is invoked.
Fixes: http://tracker.ceph.com/issues/15364 Signed-off-by: Jason Dillaman <dillaman@redhat.com>
osd: cancel scrub if noscrub is set for pool or all
The sched_scrub() method can be called by various code path, such as
OSD::tick() or triggered by a scrub_reserve_reply message.
The sched_scrub() will check whether or not the noscrub is globally set or
set for a specified pool before really starting to schedule a scrub job.
However, if we set noscrub flag for a specified pool, there are other pools
for which scrub are still legal and thus shall be granted.
The problem here is that we may stopping a pg's scrub in an intermidate stage
due to setting of the corresponding pool's noscrub flag whithout releasing
the reservation. Which as a result shall prevent other pgs of a different
pool from going scrubbing because we have already hit the reservation limit.
osd: reset tp handle when search for boundary of chunky-scrub
One of our tests in our local testbed shows that if the number of snapshots
become extremely huge, the process of chunky-scrub() may encouter
heart-beat failure. This is because it takes a real long time for the
procedure to traverse and determine the boundary for a single run of
chunk scrub under this case.
This pr tries to solve the above the problem by resetting the tp handle
passed in once in a while(after a certain number of loops, 64 by default)
since the search can become very time-consumptive. Furthermore, the
BUILD_MAP stage later on shall encouter the same problem but has already
got fixed in the same way. Therefore, although the test case is rare,
but this change is defensive and make our code strong and thus shall be
considered as worthwhile.
Sage Weil [Wed, 6 Apr 2016 01:26:06 +0000 (21:26 -0400)]
os/bluestore: use short, relative paths with bluefs
If we're using bluefs, only pass in the short relative
path (db, db.wal, db.slow). The leading components
are ignored and only lead to errors if the configuration
provides relative paths that do not match (e.g., if one
if using ceph-objectstore-tool).
Fixes: http://tracker.ceph.com/issues/15376 Signed-off-by: Sage Weil <sage@redhat.com>
Gentoo's normal build process uses a sandbox to catch writes outside the
build environment; this includes providing a value other than /tmp for
TMPDIR. Use TMPDIR by default for CEPH_BUILD_VIRTUALENV.
Signed-off-by: Robin H. Johnson <robin.johnson@dreamhost.com>
Sage Weil [Tue, 5 Apr 2016 20:37:25 +0000 (16:37 -0400)]
mds: fix legacy layout decode with pool 0
If you data pool was pool 0, this was transforming
that to -1 unconditionally, which broke upgrades. We
only want do that for a fully zeroed ceph_file_layout,
so that it still maps to a file_layout_t. If any fields
are set, though, we trust the fl_pgpool to be a valid
pool.
Sage Weil [Mon, 4 Apr 2016 18:39:18 +0000 (14:39 -0400)]
os/bluestore/BlueFS: revamp bdev ids
You cannot tell from the old bdev vector which device
was which.
- use a fixed id for each type/slot
- go from fast(small) to slow(big)
- normalize the allocation fallback to try any slower
device.
- clean up the BlueStore instantiation/setup accordingly
Erwan Velu [Thu, 24 Mar 2016 14:26:55 +0000 (15:26 +0100)]
tests: Removing one ceph-dencoder call in check-generated.sh
The first ceph-dencoder call is very unlikely to fail and represent a
bottleneck as the parallel computation are only done one this test is
completed.
The idea of this patch is to run immediately the 4 dencoders process in
parallel and check the resulting error code. If one fail then we report the
failure.
As the failure is very unlikely, that saves time and makes the code
simplier too.
Erwan Velu [Wed, 23 Mar 2016 10:13:48 +0000 (11:13 +0100)]
tests: Avoiding a fixed 10sec sleep in test_mon_cephdf_commands()
The current code was waiting 10s to expect the file being put.
If the file was put in a shorter time than 10s, the test just waits for
nothing reducing the execution speed of that test.
This patch simply check if the file is actually available every second
during 10sec to exit prematurely.
This patch saves exactly 10 sec on a local system, surely a little bit
less on an infra but still saves time. Signed-off-by: Erwan Velu <erwan@redhat.com>
Erwan Velu [Wed, 23 Mar 2016 09:45:33 +0000 (10:45 +0100)]
tests: Optmizing sleep sequence in cephtool/test.sh
The actual code double the wait time between two calls leading to a
possible 511s of waiting time which sounds a little bit excessive.
This patch offer to reduce the global wait time to 300s and test more
often the rados status to exit the loop earlier. In a local test, that
saves 6 secs per run. Signed-off-by: Erwan Velu <erwan@redhat.com>
Erwan Velu [Tue, 22 Mar 2016 10:20:24 +0000 (11:20 +0100)]
tests: Reducing sleep loops in ceph_objectstore_tool
This python script is making excessive sleep calls while running some
ceph commands.
Waiting up to 5 seconds to get the proper health status can be shorten
to avoid the worst case of waiting almost 5 seconds for nothing.
This patch removes also two sleeps calls after a wait_for_health call
which is already supposed to provides a clean state. Waiting
respectively 20 & 15 seconds after that call is just loosing time which
is precious at make check time.
Erwan Velu [Mon, 21 Mar 2016 15:20:25 +0000 (16:20 +0100)]
tests: Reducing sleep time for osd to be up
OSDs are taking some time to be up but waiting 10 secs seems execessive
here between two loops. In the worst case, we can be in a situation of
waiting 10secs for nothing as we are just a few microsecs after the osd
is up.
This patch simply reduce the sleep from 10 to 1 seconds. Signed-off-by: Erwan Velu <erwan@redhat.com>
Erwan Velu [Mon, 21 Mar 2016 10:47:51 +0000 (11:47 +0100)]
tests: Making "objectstore" calls parallel in osd-scrub-repair.sh
osd-scrub-repair is making several similar objectore calls in a
sequential way while they could be easily parallelized.
Each single objectore call can spent up to dozen of seconds so making
the call parallel is saving a lot of time while keeping the code pretty
simple.
This particular patch saves approx. 2 minutes on the actual code on a recent
laptop. The global running time of osd-scrub-repair drops from 9m33 to
7m37 ! Signed-off-by: Erwan Velu <erwan@redhat.com>
projects / ceph.git / log