Thanks for your reply, Yan! Could you give more explanation about the mechanism for how an ESlaveUpdate::OP_PREPARE log event is prevented from being trimmed before slave mds receiving MMDSSlaveRequest::OP_FINISH message from master? It seems only when doing replay can an ESlaveUpdate log event be added to LogSegment::slave_updates, which helps to prevent the log event from being trimmed. Suppose a scenario that slave mds has journaled log event, sent an OP_LINKPRPEACK to master, then trimmed the log event, and crashed. The master also crashed before receiving the ACK message. So there will no log events to be replayed for both master and slave, but slave mds has modified the inode link count, and no way to rollback. I have been stuck in this question for a few days, can't figure it out. Sincerely hoping you or anyone else can give some tips. Thanks! Yan, Zheng <ukernel@xxxxxxxxx> 于2020年3月23日周一 下午12:34写道： > > On Sun, Mar 22, 2020 at 3:40 PM Xinying Song <songxinying.ftd@xxxxxxxxx> wrote: > > > > Hi, everyone: > > Could anybody give some tips about how `mdr->slave_commit` is called? > > > > As for `link_remote()`, steps are as follows: > > 1. master mds sends OP_(UN)LINKPREP to salve mds. > > 2. slave mds replys OP_LINKPREPACK to master mds after its journal has > > been flushed. > > 3. master mds continues to process the client request. > > > > I only find out there is a chance in MDCache::request_finish() that > > `mdr->slave_commit` will be called. However, after a successful > > journal flush, slave mds only sends an ACK to master mds and bypasses > > MDCache::request_finish(). > > So when or where is `mdr->slave_commit` called? > > > > Thanks! > > master calls MDCache::request_finsih(), > MDCache::request_drop_foreign_locks() sends > MMDSSlaveRequest::OP_FINISH message to slaves. slaves call > MDCache::request_finsih() when receiving the message.
