Joaquim Rocha [Fri, 5 Jun 2015 12:48:41 +0000 (14:48 +0200)]
build: Add info about tests to --with-debug option
The configure's --with-debug option builds also some of the tests
so this should be mentioned in its doc string in order to let users
know how to build all the tests.
David Disseldorp [Fri, 29 May 2015 16:30:54 +0000 (18:30 +0200)]
tests: fix test_activate_dmcrypt uuid usage
4601e10800a63cf0e03108e1da0bf11c19c33e26 introduced a regression in that
an empty (uninitialised) OSD uuid is passed to test_pool_read_write for
IO. As a result, the "rados put" request times out causing test failure.
This change ensures that a correct OSD uuid is passed to
test_pool_read_write.
Jason Dillaman [Thu, 30 Apr 2015 20:04:28 +0000 (16:04 -0400)]
librbd: simplify state machine handling of exclusive lock
It is expected that all IO is flushed and all async ops are cancelled
prior to releasing the exclusive lock. Therefore, replace handling of
lost exclusive locks in state machines with an assertion.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
In order to support the invariant that all state machine
callbacks occur without holding locks, transitions that
don't always involve a librados call should queue their
callback.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Jason Dillaman [Thu, 7 May 2015 19:32:27 +0000 (15:32 -0400)]
librbd: disable lockdep on AioCompletion
It is only used by clients and it causes a large slowdown
in performance due to the rate at which the lock is constructed/
destructed for each IO request.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Jason Dillaman [Thu, 30 Apr 2015 17:40:16 +0000 (13:40 -0400)]
librbd: complete cache read in a new thread context
The ObjectCacher complete the read callback while still holding
the cache lock. This introduces lock ordering issues which are
resolved by queuing the completion to execute in a clean (unlocked)
context.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Jason Dillaman [Thu, 30 Apr 2015 17:29:12 +0000 (13:29 -0400)]
common: lockdep now support unregistering once destructed
librbd use of an image hierarchy resulted in lock names being
re-used and incorrectly analyzed. librbd now uses unique lock
names per instance, but to prevent an unbounded growth of
tracked locks, we now remove lock tracking once a lock is
destructed.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Kefu Chai [Thu, 4 Jun 2015 09:45:09 +0000 (17:45 +0800)]
test: fix the plugin_exists()
in 8e61a99, we try to init the plugin when user set a profile using
"ceph osd erasure-code-profile set <profile-name> <profile>", so
if user passes in an unknown plugin, ceph will reject it right away,
instead of loading the plugin when "ceph osd crush rule create-erasure".
Kefu Chai [Thu, 4 Jun 2015 03:53:55 +0000 (11:53 +0800)]
install-deps.sh: do not create "wheelhouse" unless it's ready
* only create "wheelhouse" directory for tox when it is populated
with all packages in *requiresments.txt. before than, the wheels
are put in "wheelhouse-wip"
Boris Ranto [Wed, 3 Jun 2015 10:24:48 +0000 (12:24 +0200)]
common/Cycles.cc: skip initialization if rdtsc is not implemented
The Cycles initialization gets stuck in infinite loop if rdtsc is not
implemented. This patch fixes the issue by quitting the initialization
if rtdsc fails.
The patch was cherry-picked from ubuntu patch by James Page, see
Sage Weil [Wed, 3 Jun 2015 18:57:34 +0000 (14:57 -0400)]
upstart: limit respawn to 3 in 30 mins (instead of 5 in 30s)
It may take tens of seconds to restart each time, so 5 in 30s does not stop
the crash on startup respawn loop in many cases. In particular, we'd like
to catch the case where the internal heartbeats fail.
This should be enough for all but the most sluggish of OSDs and capture
many cases of failure shortly after startup.
Fixes: #11798 Signed-off-by: Sage Weil <sage@redhat.com>
Loic Dachary [Sun, 17 May 2015 22:06:06 +0000 (00:06 +0200)]
erasure-code: verify the profile content matches get_profile()
The profile stored by the plugin may be different from the one set by
the user: it includes defaults. When the plugin is initialized, the
profile is modified to include the default values. Verify that the
modified profile matches what the get_profile() method returns, to guard
against inconsistencies from the erasure code plugin implementation.
Loic Dachary [Sun, 17 May 2015 21:53:42 +0000 (23:53 +0200)]
mon: normalize erasure-code profile for storage and comparison
An erasure-code profile set by the user may be modified by the erasure
code plugin, most of the time to add default values for domain failure,
techniques etc.
Whenever the monitor gets an erasure code profile from the user or the
configuration file, it uses it to initialize the corresponding erasure
code plugin and:
* validate the profile and get an error if it is invalid
* get a normalized profile
The normalized profile is stored in the OSDMap. Should the user try
to set the same erasure code profile with the different values that lead
to the same normalized form, the modification will be accepted as a
noop, as if the same values were given. For instance:
ceph osd erasure-code-profile set myprofile k=2
ceph osd erasure-code-profile set myprofile k=2 m=1
are the same because the default value for m is 1 for the default
jerasure plugin.
If the normalized form is not used for storage and comparison, the
second call with m=1 will fail and require --force to override
myprofile, although the user can read from the documentation that it
matches the default value.
Loic Dachary [Mon, 1 Jun 2015 17:50:05 +0000 (19:50 +0200)]
erasure-code: implement get_profile for every plugins
The ErasureCode::init function is implemented to store the profile and
is called by the init method of each plugin. The
ErasureCode::get_profile function is implemented to return the profile
that was stored. A specialized ostream<< function is implemented to
facilitate the display of the profile.
Loic Dachary [Mon, 1 Jun 2015 17:46:50 +0000 (19:46 +0200)]
erasure-code: expect all plugins to implement get_profile
Add the get_profile method to the interface and make it a pure virtual.
Each plugin is expected to return the profile currently in use. Although
the profile is also stored in the OSDMap, it provides a convenient
introspection method to validate that the profile being set is indeed
the profile being used.
projects / ceph.git / log