mds: Client syncfs is slow (waits for next MDS tick)

[taodd]

tracker url: http://tracker.ceph.com/issues/20129
Signed-off-by: dongdong tao tdd21151186@gmail.com

[ukernel]

we should only call flush_mdlog_sync() once when there are pending request or flushing caps. mount_cond can get signaled prematurely, calling flush_mdlog_sync() each time mount_cond get signaled creates unnecessary overhead on mds. Besides, we should call flush_mdlog_sync() after flushing dirty caps

[taodd]

1 we are inside the loop "while(!mds_requests.empty())", so i think this means there are at least 1 pending requests ?
2 client_clock is still hold here until next statement, so I don't understand why mount_cond would get signaled prematurely.
3 if we don't add flush_mdlog_sync() here, in this while loop, then next statement (mount_cond.Wait(client_lock)) will still have to wait for next mds tick, right?

4 you said flushing dirty caps, flush_caps_sync() is used to flush dirty caps, right ? and it is been called later in function "Client::unmount";
may be i misunderstand your comment ?

[ukernel]

handle_client_reply() signals mount_cond. If there are N pending requests, flush_mdlog_sync() get called N times.

[ukernel]

My point is reducing the messages/requests that trigger mdlog->flush to as few as possible

[taodd]

yeah, you are right, flush_mdlog_sync() in the while loop would be trigged N times
I should call this before this while loop and add check in flush_mdlog_sync

[jcsp]

This has passed tests + is ready to merge, @taodd please could you clean up the commit messages, they should be something like this:

client: signal MDS to flush log when doing a syncfs

<...more description text...>

Fixes: http://tracker.ceph.com/issues/20129
Signed-off-by: dongdong tao <tdd21151186@gmail.com>

Have a look at other recent commits in the repository for examples.

[taodd]

updated the commit message

[jcsp]

@ukernel @taodd anyone have any thoughts about how to handle upgrades? I should have asked this before merging really :-), but we definitely need an answer before we release luminous -- MDSs currently abort if they see an unexpected CEPH_SESSION_* in a MClientSession, so the client probably needs a way to avoid sending it to older MDSs.

[taodd]

yes, we should, how do we identify older MDSs ?

[jcsp]

Turns out we already had a handy luminous feature bit to check, I've created a PR to handle upgrades #15805