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-926 Lustre <p>The llapi_file_fget_lov_uuid() API call appears to be broken in 2.1. That calls llapi_file_fget_lov_uuid() which seems to be where the failure is:</p> <p> error: can't get lov name.: Inappropriate ioctl for device (25)</p> <p>This IS for a file in a lustre filesystem.</p> <p>Note that a user found this by trying the llapi example in the lustre manual. There are at least two obvious bugs in that example (just try compiling it, you'll see them), so that should be fixed as well.</p> LU-926

llapi_file_fget_lov_uuid() is broken in 2.1

Bug Minor Resolved Duplicate Zhenyu Xu Christopher Morrone Wed, 14 Dec 2011 18:58:48 +0000 Sat, 28 Mar 2020 05:16:11 +0000 Fri, 16 Dec 2011 18:26:07 +0000 Lustre 2.1.0 0 3 <p>Sorry, it is llapi_lov_get_uuids() that is broken because it calls llapi_file_fget_lov_uuid(). It turns out that it works for directories, but not for files.</p> <p>It looks like between 1.8 and 2.1 the OBD_IOC_GETNAME handler for files was dropped. Directories still handle it. Was that done for any particular reason, or was it just an oversight of CLIO?</p> <p>Should we just reintroduce the handler, or do we need to make the llapi work differently?</p> <p>I fixed this in my client side patch for <a href="https://jira.whamcloud.com/browse/LU-80" title="Wide striping support" class="issue-link" data-issue-key="LU-80"><del>LU-80</del></a>. Please give it a try.</p> <p><a href="http://review.whamcloud.com/#change,1194" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,1194</a></p> <p>YuJian</p> <p>I am assigning this to you as it seems that this is related to the wide striping work</p> <p>Peter</p> <p>This is not really related to wide striping, although some of the same code may be touched.</p> <p>James, I don't think that will address it. That only appears to address llapi_file_get_lov_uuid(), which already has the path name and can simply look up the info from the parent directory.</p> <p>We need llapi_file_fget_lov_uuid() (note the "fget") fixed, which only has a file descriptor.</p> <p>And clearly our llapi regression tests are sorely lacking. <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>ok Chris. In that case I do not want to distract Yu Jian from Wide Striping. Bobijam can you look into this?</p> <p>Chris, this can happen if the userspace application is being built with a 32-bit compiler on a 64-bit kernel, or vice versa. Is this on a PPC client, or an x86_64 client?</p> <p>I'm looking at the examples in the documentation. Those will be addressed in a separate <a href="https://jira.whamcloud.com/browse/LUDOC-28" title="improve documentation examples for liblustreapi functions" class="issue-link" data-issue-key="LUDOC-28"><del>LUDOC-28</del></a> bug.</p> <p>This is a problem on all architectures, I think. The test was a plain ol' x86_64 RHEL6 client.</p> <p>Between 1.8 and 2.1 the lustre/llite/file.c ioctl handler lost support for OBD_IOC_GETNAME. It now tries to pass it down through various layers instead of returning the LOV name immediately like it used to. Passing it down to all of the OSCs in the LOV is clearly not the correct thing to do.</p> <p>lustre/llite/dir.c still has the OBD_IOC_GETNAME handler, so it works fine for directories.</p> <p>file ioctl for OBD_IOC_GETNAME has been added in master branch in <a href="https://jira.whamcloud.com/browse/LU-680" title="superblock &lt;-&gt; mount point mapping" class="issue-link" data-issue-key="LU-680"><del>LU-680</del></a>, commit 8d935e6d3137bc4678ca2f22c1a30d34474cf677, patch at <a href="http://review.whamcloud.com/1373" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/1373</a></p> <p>Ah, yes, that looks like it will fix it.</p> <p>This should probably be included in 2.1.1.</p> <p>I have pulled <a href="http://review.whamcloud.com/1373" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/1373</a> into our tree and verified that it works. I like the new getname call as well!</p> <p>Thanks for the update Chris. I will close this ticket as a duplicate of <a href="https://jira.whamcloud.com/browse/LU-680" title="superblock &lt;-&gt; mount point mapping" class="issue-link" data-issue-key="LU-680"><del>LU-680</del></a>.</p> <p>As long as you are tracking this for inclusion in 2.1.1 somewhere, that is fine.</p> <p>Yes I am <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> Related LUDOC-28 Development Rank 1|hzvhmf: Rank (Obsolete) 6504 Severity