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

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.1.0
• Type: Bug
• Priority: Minor
• Reporter: Christopher Morrone
• Assignee: Zhenyu Xu
• Resolution: Duplicate
• Severity: 3

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 li...

Comments

[Christopher Morrone]

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.

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?

Should we just reintroduce the handler, or do we need to make the llapi work differently?

[James A Simmons]

I fixed this in my client side patch for LU-80. Please give it a try.

http://review.whamcloud.com/#change,1194

[Peter Jones]

YuJian

I am assigning this to you as it seems that this is related to the wide striping work

Peter

[Christopher Morrone]

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.

[Peter Jones]

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

[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.

[Christopher Morrone]

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.

[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]

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

This should probably be included in 2.1.1.

[Christopher Morrone]

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

[Peter Jones]

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

[Christopher Morrone]

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

[Peter Jones]

Yes I am