We don't have a great way to guarantee mdsmap updates, but they
should happen on their own and we can loop. Closes#1518.
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
You can still say "rpmbuild -ba --with tcmalloc ceph.spec"
if you have it.
Add BuildRequires on google-perftools when building with tcmalloc.
Ensure it's the right architecture.
Signed-off-by: Tommi Virtanen <tommi.virtanen@dreamhost.com>
We were previously setting up a reference loop. But the only way
to get Sessions is via the Connection, so let's just give Sessions
the pointer, and give Connections a counted ref.
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
We can't do that if we're trying to be Valgrind-clean, so just
make the lock name part of the class.
As best I can tell, that ordered initialization is safe because
data members are initialized in the order they are declared. See eg
http://xenon.arcticus.com/c-morsels-initializer-list-execution-order
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
We need to take the ondisk read lock on src oids for multiobject operations
(like clonerange) to ensure that written data has hit disk before we
clone it elsewhere.
Order of acquisition doesn't actually matter here, since the ondisk locks
are all leaves in the lock dependency hierarchy.
Signed-off-by: Sage Weil <sage@newdream.net>
There should be no difference between an object with a key identical to
its name and an object with the same name but no key.
Signed-off-by: Samuel Just <samuel.just@dreamhost.com>
If info.pgid is in creating_pgs, we should use the history from
creating_pgs. The history passed in will be an empty history from a
creation probe in that case.
Signed-off-by: Samuel Just <samuel.just@dreamhost.com>
If we get an IMPORT and don't have the inode, add it. This fixes a race
like:
mds0 -> client .. mknod reply (or similar)
mds0 -> mds1 .. migrate cap
mds1 -> client .. send IMPORT
client <- mds1 .. rx IMPORT, but don't have inode
client <- mds0 .. rx mknod reply, add it.
With this fix, we add the inode and set up the cap on IMPORT, and when we
get the mknod reply we update the inode immutable fields that aren't
present in the cap message (rdev, symlink target).
Fixes: #1513
Signed-off-by: Sage Weil <sage@newdream.net>
Unlike other lock transitions, we are moving to an _unstable_ state and
then taking our (x)lock. That means that if we don't actually finish for
some reason (lock order changes, request is canceled, whatever) we leave
things in an unstable state--in this case, PREXLOCK, where nothing else
will touch it.
Call cancel_lock in drop_locks (or in acquire_locks when the order changes)
to clean up after an aborted lock attempt.
Original but reproduced (though not easily) by multimds collection task
fsstress_thrash_subtrees.yaml.
Fixes: #1425
Signed-off-by: Sage Weil <sage@newdream.net>
Keep track of which lock we are currently working on locking in the
Mutation. Use helpers to make sure we start/finish locking in a sane
way.
Signed-off-by: Sage Weil <sage@newdream.net>
