[LU-926] llapi_file_fget_lov_uuid() is broken in 2.1

• Type: Bug
• Resolution: Duplicate
• Priority: Minor
• Affects Version/s: Lustre 2.1.0
• Severity: 3
• Assignee: Zhenyu Xu
• Reporter: Christopher Morrone (Inactive)

Description

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:

error: can't get lov name.: Inappropriate ioctl for device (25)

This IS for a file in a lustre filesystem.

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.

Issue Links

• is related to: LUDOC-28 improve documentation examples for liblustreapi functions

Comments

[Peter Jones]

Yes I am

[Christopher Morrone (Inactive)]

As long as you are tracking this for inclusion in 2.1.1 somewhere, that is fine.

[Peter Jones]

Thanks for the update Chris. I will close this ticket as a duplicate of LU-680.

[Christopher Morrone (Inactive)]

I have pulled http://review.whamcloud.com/1373 into our tree and verified that it works. I like the new getname call as well!

[Christopher Morrone (Inactive)]

Ah, yes, that looks like it will fix it.

This should probably be included in 2.1.1.

[Zhenyu Xu]

file ioctl for OBD_IOC_GETNAME has been added in master branch in LU-680, commit 8d935e6d3137bc4678ca2f22c1a30d34474cf677, patch at http://review.whamcloud.com/1373

[Christopher Morrone (Inactive)]

This is a problem on all architectures, I think. The test was a plain ol' x86_64 RHEL6 client.

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.

lustre/llite/dir.c still has the OBD_IOC_GETNAME handler, so it works fine for directories.

[Andreas Dilger]

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?

I'm looking at the examples in the documentation. Those will be addressed in a separate LUDOC-28 bug.

[Peter Jones]

ok Chris. In that case I do not want to distract Yu Jian from Wide Striping. Bobijam can you look into this?

[Christopher Morrone (Inactive)]

This is not really related to wide striping, although some of the same code may be touched.

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.

We need llapi_file_fget_lov_uuid() (note the "fget") fixed, which only has a file descriptor.

And clearly our llapi regression tests are sorely lacking.