Formerly, we only built gtest when doing 'make check'. However, the
librados-api tests, which are built in debug mode for the 'all' target,
also use gtest. So build it when needed.
Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
Use this capability so that wait_for_new_map can specify a specific
map it wants go get. I am extending the sins of the fathers by
allowing a default value of 0 for the epoch here, but removing it
is even clumsier and there are lots of uses where it legitimately
doesn't care what epoch it gets.
Fixes#1383.
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
We maintain last_change properly now, so we can use it at any time.
It may still be possible that we can get PGs with the wrong epoch
created if, somehow, we do multiple expansions without
check_osd_map getting called between them. That's a pretty unlikely
occurrence, though, and I'm not sure that it's actually possible.
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
We were making a few changes that didn't update this value, which
can cause problems when creating new PGs.
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
Previously it was possible to lose PG creations if a monitor election
happened at the right time. The issue would get rectified on the
next OSDMap update, but that could take...a while. (My observed time
when I discovered the bug had it go without creation for 43 minutes,
at which point I killed it.)
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
We are cheating with the shared libs by making small API changes without
bumping the soname. Bind users to a matching version to minimize user
pain. When the APIs become fully stable these will need to go away.
Fixes: #1354
Signed-off-by: Sage Weil <sage@newdream.net>
We can have two renames for the same file in flight to the journal. Stack
them up in a list. The old project_subtree_rename() should have asserted
that the item wasn't already in the map before inserting it to catch this
at the front end. Now it doesn't matter; it's a list.
Signed-off-by: Sage Weil <sage@newdream.net>
AFAICS we got this wrong in b794aeb39, which is annoying given I remember
thinking reasonably carefully about it.
The current reasoning: the request operates on the dentry target
directory from the MDS's perspective; that's where the request needs to go.
Signed-off-by: Sage Weil <sage@newdream.net>
* Don't allow parse_argv, parse_env, or parse_config_files to be used
after threads have been started.
* Don't allow set_val to be used to change unsafe variables after
threads have been started.
* Test
Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
Don't allow string-valued configuration items to be changed using
injectargs unless they have observers. Otherwise, we could have
crashes, since one thread could be reading the std::string's internal
buffer after another thread frees that buffer during assignment.
Write a unit test to validate this behavior.
Also test that we can turn on and off the log_file using injectargs.
This is something that injectargs often gets used for in practice.
Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
5bb07df6aa tried to do this, but it
only set them properly for localized PGs. Whoops!
Additionally, we do NOT want to do this for new PGs in pre-existing
pools. Unfortunately, we have no way of guaranteeing that these new
PGs in old pools have the right epoch -- the data doesn't exist.
I'll discuss with other team members; it's possible that last_change
is in fact supposed to deal with this and simply doesn't.
Meanwhile, I've created a new bug to track this: #1365.
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
* any place where we know a set_val can't fail should be set_val_or_die
* in private md_config_t functions that need the mutex, assert that the
mutex is locked
* make md_config_t::expand_meta private, since nobody uses it outside of
the class.
Signed-off-by: Colin McCabe <colin.mccabe@dreamhost.com>
