https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-13010 Lustre <p>For a file or directory flagged with Protect(P) state under the protection of EX WBC lock, the open() system call does not need to communicate with MDS, can also be executed locally in MemFS of Lustre WBC.</p> <p>However, Lustre is a stateful filesystem. Each open keeps a state on the MDS. We must keep transparency for applications once the EX WBC lock is cancelled. To achieve this goal, each local open will be recorded in the inode’s open list (or maintain pre dentry?); When the EX WBC lock is cancelling, it must reopen the files in the open list from MDS.</p> <p>For regular files, after reopened from MDS, the metadata and data I/O can use the reopened file handle. It is transparent to applications.</p> LU-13010

WBC: Reopen the file when WBC EX lock revoking

Technical task LU-10938 Blocker Open Unresolved WC Triage Qian Yingjin Tue, 26 Nov 2019 09:29:40 +0000 Mon, 10 Jan 2022 01:17:57 +0000 0 6 <p>Ideally, it would make sense to create the files on the MDS with an open call, with a small change to allow passing the number of openers on the client. That avoids to send an extra RPC to the MDS. </p> <p>It makes sense to align the implementation of <tt>MDS_OPEN</tt> RPC generation with the "<a href="http://wiki.lustre.org/Simplified_Interoperability#MDS_OPEN_request_replay" class="external-link" target="_blank" rel="nofollow noopener">Simplified Interoperability MDS_OPEN request replay</a>" architecture. In particular, change the client over to generating new <tt>MDS_OPEN</tt> RPCs from the VFS file handles for all recovery so that there is a single unified mechanism for handling this. This will also allow simplifying the client RPC replay code to remove <tt>mod_open_req</tt>, <tt>mod_close_req</tt>, <tt>rq_replay</tt>, and a considerable amount of related complexity in <tt>ptlrpc</tt> and <tt>mdc</tt> code.</p> <p>There <em>may</em> need to be a small amount of extra saved state in the Lustre file handle (e.g. <tt>rq_transno</tt>) after the RPC is committed on the MDS and the RPC is dropped from <tt>imp_replay_list</tt> in order to generate a new <tt>MDS_OPEN</tt> RPC during replay. However, it may also be enough for the <tt>MDS_OPEN</tt> RPC to generate a fake <tt>rq_transno &lt; exp_last_committed</tt> so that it is before any other real RPC sent during recovery.</p> <p>Once this cleanup is done, then WBC open file handles would just generate <tt>MDS_OPEN</tt> RPCs directly during WBC cache flush, without the need to save a lot of extra state on the client if many files are open.</p> <p>Yingjin Qian (qian@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/38423" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/38423</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13010" title="WBC: Reopen the file when WBC EX lock revoking" class="issue-link" data-issue-key="LU-13010">LU-13010</a> wbc: reopen files when root WBC EX lock is revoking<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 72e3461f56db0a9de513aba4547518b4f1d6e943</p> <p>For directories, it must be handled carefully for the -&gt;readdir() call. <br/> Currently the mechanism adopted by MemFS (tmpfs) is to simply scan the in-memory sub dentries of the directory in dcache linearly to fill the content returned to readdir call: -&gt;dcache_readdir(). <br/> While Lustre new readdir implementation is much complex. It does readdir in hash order and uses hash of a file name as a telldir/seekdir cookie stored in the file handle. <br/> Thus, we must find a method to bridge two implementation firstly.</p> Related LU-5703 LU-10938 Development Rank 1|i00pxb: Rank (Obsolete) 9223372036854775807