This lets us issue the most leases/caps possible. It also ensure we can
issue caps in the snapped namespace when we are still on the head inode
(previously, releasing the rdlock twiddled the state, the client didn't
get say Frc, and hung indefinitely).
This mirrors the logic in cc8f5ac47c77d1e336e16d8deb024d507e0e8c59. Make
the renamed inode first match the destdn to avoid problems down the line.
Do this after we've (potentially) cowed the inode in the journal_cow_dentry
on srcdn.
We can get a dn->first that is greater than the parent dir's seq. Notably,
when we do something like
mkdir foo
mkdir foo/.snap/a
rmdir foo/.snap/a
rmdir foo
Here, the foo dentry has a high seq, and subsequent mkdir foo should make
sure we give the new foo dir inode the same seq (and not a lower one from
the parent). Otherwise, things get confused later on.
add_past_parent hack.
Adjusted pop_projected to invalidate caches if needed, and removed
project_past_parent's deletion of projected snaprealm.
Removed add_past_parent.
For now, delete the projected version of the inode so it matches (or fixes?)
old behavior. Once users have been fixed to use pop_projected_snaprealm et al,
remove that.
The problem is if we revoke caps, nothing is dirty, but we do writeback
because we are adjusting max_size. Then we have to wait for the log to
flush even though the revocation should proceed immediately. To move
things along, flush the log immediately.
This still isn't ideal.. it would be nice to allow the locking to continue
and adjust max_size in parallel, but that isn't always possible, and will
require some more thought.
This just avoids l=-1 from showing up in the logs, makes the logic a bit
cleaner (keeps missing and missing_loc in sync).
Signed-off-by: Sage Weil <sage@newdream.net>
Depend on libgoogle-perftools0, not libtcmalloc-minimal0, since we link
against libtcmalloc, not libtcmalloc-minimal. Duh.
Signed-off-by: Sage Weil <sage@newdream.net>
- If we are non-auth, stick with the snap, and the auth will do the
inference.
- If we are auth, the head had better exist, because our lock is
pinned in an unreadable state for some reason. Assert as much.
This fixes a race with successive elections: we may see a new election
(X+1), then get a victory (X). The victory is ignored (rightly so). But
then a paxos follows that which assumes X, and our check was against
mon_epoch, only updated on election victory.. and we are inconsistent and
crash.
So, just get rid of private mon_epoch and use the elector's value.
Signed-off-by: Sage Weil <sage@newdream.net>
