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-3397 Lustre <p>Similar to the "import" file on the client for each client-to-server connection, it would be useful to have a file on the server in the per-client directory <tt>obdfilter/*/exports/$NID/export</tt>. This would contain export connection information as in the "import" file (connect flags, etc. and also as described in <a href="https://jira.whamcloud.com/browse/LU-3386" title="improve osc/mdc &quot;imports&quot; connect data" class="issue-link" data-issue-key="LU-3386"><del>LU-3386</del></a>). </p> LU-3397

Create per-client "export" /proc file on server for each client connection

Improvement Minor Resolved Fixed Emoly Liu Andreas Dilger easy Sat, 25 May 2013 06:44:18 +0000 Fri, 4 May 2018 05:28:40 +0000 Tue, 6 Feb 2018 05:00:07 +0000 Lustre 2.11.0 0 9 <p><a href="http://review.whamcloud.com/6713" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6713</a></p> <p>We can mark this a 2.7 project.</p> <p>I have been working with the patch in question and have found a issue with the location of where to place the data. It is not true that <br/> obdfilter/&#42;/exports/$NID/export is a per client directory. For example if you build all of lustre on one node and cat obdfilter/&#42;/exports/$NID/uuid you get </p> <p>62fde21f-fbc4-cced-7862-e1ccb9cdea09<br/> lustre-MDT0000-mdtlov_UUID</p> <p>So it is multiple values. For your export to do the similar behavior it would have multiple entries. Do we really want that? I think a better approach would be to create directory entries such as obdfilter/*/exports/"obd-device"/export instead.</p> <p>James, Yangsheng ever had a similar idea in <a href="http://review.whamcloud.com/#/c/9857/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/9857/</a>, but Andreas thought it would break all tools that are using the per-NID statistics, and also, the only time there were multiple mounts on the same NID would be during testing.</p> <p>I don't mind discussing it again.</p> <p>Trying to revive this patch again for 2.9.</p> <p>What about having a single <tt>obdfilter/&#42;/exports/$NID/export</tt> file, but in the case there are multiple exports for the same NID (e.g. client connecting to multiple OSTs on one node} then there would be multiple entries in the <tt>export</tt> file? Since it is YAML formatted, it would be possible to prefix the data output with <tt>device: $obd_name</tt> or similar to disambiguate them. This would avoid overhead from having to open/parse/close multiple <tt>export</tt> files, and also avoid the naming issue for those files.</p> <p>The other option is to have files like <tt>.../export-$obd_name</tt> and each one has only the data for that device. The complexity I see here is that there would be a bunch of these files (1-8 typically), that would likely always be read together, and accessing them needs a priori knowledge of what the device names will be, and they will be different for every server.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/6713/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/6713/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-3397" title="Create per-client &quot;export&quot; /proc file on server for each client connection" class="issue-link" data-issue-key="LU-3397"><del>LU-3397</del></a> lprocfs: create "export" /proc file on server<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: b4b773466a0f3a178364e62b8549de08a3f9ce32</p> <p>Landed for 2.11</p> Related LU-8066 LU-3386 LU-10972 Development Rank 1|hzvrvb: Rank (Obsolete) 8412