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-7964 Lustre <p>Lustre liblustreapi does not use the regular file's getstripe interface, I'm thinking that we could get rid of the interface. And this ticket is for tracking whether there is any application uses this interface.</p> LU-7964

tracking whether there is a direct application usage of regular file LL_IOC_LOV_GETSTRIPE ioctl interface

Bug Minor Resolved Won't Fix Zhenyu Xu Zhenyu Xu Thu, 31 Mar 2016 08:55:13 +0000 Thu, 31 Oct 2019 05:18:41 +0000 Thu, 31 Oct 2019 05:18:41 +0000 0 7 <p>Bobi Jam (bobijam@hotmail.com) uploaded a new patch: <a href="http://review.whamcloud.com/19257" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/19257</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7964" title="tracking whether there is a direct application usage of regular file LL_IOC_LOV_GETSTRIPE ioctl interface" class="issue-link" data-issue-key="LU-7964"><del>LU-7964</del></a> llite: add a deprecation console message<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 18c080edeef315b49f465f1f1fc47d5eb8a1f0d8</p> <p>no, this does not change the liblustre APIs</p> <p>What is difference between LL_IOC_LOV_GETSTRIPE and IOC_MDC_GETFILESTRIPE? </p> <p>According to the code, LL_IOC_LOV_GETSTRIPE is act upon the opened file handle, and IOC_MDC_GETFILESTRIPE is upon the parent fd, and the filename of interest is passed in the user buffer.</p> <p>It seems both are useful then, just for different use cases. I would agree that LL_IOC_LOV_GETSTRIPE is redundant with the lustre.lov extended attribute, except there is bug LDEV-310 which means lustre.lov incorrect for released files. Could we fix that one first before removing this, and then applications can read EA instead? </p> <p>At one time I looked to moving lfs <span class="error">&#91;s|g&#93;</span>etstripe to the layout api but I found problem which prevented this. See <a href="https://jira.whamcloud.com/browse/LU-2809" title="fix ll_setxattr() to always ignore ll_stripe_offset" class="issue-link" data-issue-key="LU-2809"><del>LU-2809</del></a> for details.</p> <p>That's interesting, so since there is an actual difference between the xattr and ioctl, then it seems it may be worth keeping this one around until at least lov_user_md_v4 appears and we have parity between xattr and ioctl.</p> <p>BTW, the issue I reported in LDEV-310 is stripe_count is 0 in xattr for a released file, but is still set when using ioctl. I suspect that is a bug and not intentional like <a href="https://jira.whamcloud.com/browse/LU-2809" title="fix ll_setxattr() to always ignore ll_stripe_offset" class="issue-link" data-issue-key="LU-2809"><del>LU-2809</del></a>, but I haven't tracked it down. Oh, and I'm assuming/hoping that being 0 in xattr is the bug, not the other way around. </p> <p>One important application that is using <tt>LL_IOC_LOV_GETSTRIPE</tt> is the MPI-IO library's ADIO Lustre driver, in order to determine optimal file layout for collective IO across multiple clients. Sadly, it is dereferencing the returned struct directly without checking the <tt>lmm_magic</tt> to see if the returned struct is even something it understands. It should have stopped using direct ioctl() access ages ago, and moved over to <tt>llapi_layout_get_by_path()</tt> to extract the stripe count and such.</p> <p>I see in recent testing that <tt>LL_IOC_LOV_GETSTRIPE</tt> is still being used, even by code in the Lustre tree itself, since it is triggering the error message on the console:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>lfs: using old ioctl(LL_IOC_LOV_GETSTRIPE) on [0x2000061c2:0x24:0x0], use llapi_layout_get_by_path() </pre> </div></div> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">static</span> <span class="code-object">int</span> cb_getstripe(<span class="code-object">char</span> *path, DIR *parent, DIR **dirp, void *data, struct dirent64 *de) { struct find_param *param = (struct find_param *)data; DIR *d = dirp == NULL ? NULL : *dirp; <span class="code-object">int</span> ret = 0; : : <span class="code-keyword">if</span> (d) { <span class="code-keyword">if</span> (param-&gt;fp_get_lmv || param-&gt;fp_get_default_lmv) { ret = cb_get_dirstripe(path, d, param); } <span class="code-keyword">else</span> { ret = ioctl(dirfd(d), LL_IOC_LOV_GETSTRIPE, (void *)&amp;param-&gt;fp_lmd-&gt;lmd_lmm); </pre> </div></div> <p>Won't deprecate this interface for now.</p> Related LU-9490 Development Rank 1|hzy6gf: Rank (Obsolete) 9223372036854775807 Severity