mds: don't expire log segment before it's fully flushed

Expiring log segment before it's fully flushed may cause various
issues during log replay.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: fix anchor table update

The reference count of an anchor table entry that corresponds to
directory is number of anchored inodes under the directory. But
when updating anchor trace for an directory inode, the code only
increases/decreases its new/old ancestor anchor table entries'
reference counts by one.

This patch probably resolves BUG #1850.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: check parent inode's versionlock when propagating rstats

To propagate rstats to one level up, we need lock both parent
inode's nestlock and versionlock.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: don't add not issued caps when confirming cap receipt

There is message ordering race in cephfs kernel client. We compose
cap messages when i_ceph_lock is hold. But when adding messages
to the output queue, the kernel releases i_ceph_lock and acquires
a mutex. So it is possible that cap messages are send out of order.
If the kernel client send a cap update, then send a cap release,
but the two messages reach MDS out of order. The update message
will re-add the released caps. This patch adds code to check if
caps were actually issued when confirming cap receipt.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
mds: fix CDir::_commit_partial() bug

When a null dentry is encountered, CDir::_commit_partial() adds
a OSD_TMAP_RM command to delete the dentry. But if the dentry is
new, the osd will not find the dentry when handling the command
and the tmap update operation will fail totally.

This patch also makes sure dentries are properly marked as new
when preparing new dentries and exporting dentries.

Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
osd: move tmapup into a helper

Signed-off-by: Sage Weil <sage@inktank.com>
osd: tolerate misordered TMAP updates

The previous tmap implementation requires that the update stream be
sorted or else it will behave erratically (by placing new keys in the
map out of order).  This can cause very strange failures: reads may
appear to return the correct result initially, but once intervening
keys are remove they will not... depending on how read is implemented
on the client side.

Fix this by doing the optimized updates initially, but falling back to
a slow implementation if an unsorted update is detected.  It is slow,
but such updates are rare.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: do not ENOENT on missing key on remove

The MDS may include RM ops in a tmap update for items that were already
removed: after restarting and replaying the journal, it doesn't know
which dentries were previously committed and which were not.

No other (known) users care about the error code.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: verify TMAPPUT data is sorted

The MDS may try to write unsorted data; make sure it is sorted before
we write it.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: detect (some) misordered ondisk tmaps

Detect a misordered ondisk tmap... if we are already decoding it.  We still
leave the trailing bits unchecked.

Signed-off-by: Sage Weil <sage@inktank.com>