[LU-7964] tracking whether there is a direct application usage of regular file LL_IOC_LOV_GETSTRIPE ioctl interface

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Zhenyu Xu
• Assignee: Zhenyu Xu
• Resolution: Won't Fix
• Severity: 3

Description

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.

Issue Links

• is related to: LU-9490 MPI-IO Lustre ADIO driver gets Lustre...

Comments

[Gerrit Updater]

Bobi Jam ([e-mail]) uploaded a new patch: http://review.whamcloud.com/19257
Subject: LU-7964 llite: add a deprecation console message
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 18c080edeef315b49f465f1f1fc47d5eb8a1f0d8

[Zhenyu Xu]

no, this does not change the liblustre APIs

[Robert Read (Inactive)]

What is difference between LL_IOC_LOV_GETSTRIPE and IOC_MDC_GETFILESTRIPE?

[Zhenyu Xu]

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.

[Robert Read (Inactive)]

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?

[James A Simmons]

At one time I looked to moving lfs [s|g]etstripe to the layout api but I found problem which prevented this. See LU-2809 for details.

[Robert Read (Inactive)]

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.

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 LU-2809, 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.

[Andreas Dilger]

One important application that is using LL_IOC_LOV_GETSTRIPE 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 lmm_magic 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 llapi_layout_get_by_path() to extract the stripe count and such.

[Andreas Dilger]

I see in recent testing that LL_IOC_LOV_GETSTRIPE is still being used, even by code in the Lustre tree itself, since it is triggering the error message on the console:

lfs: using old ioctl(LL_IOC_LOV_GETSTRIPE) on [0x2000061c2:0x24:0x0], use llapi_layout_get_by_path()

static int cb_getstripe(char *path, DIR *parent, DIR **dirp, void *data,
                        struct dirent64 *de)
{
        struct find_param *param = (struct find_param *)data;
        DIR *d = dirp == NULL ? NULL : *dirp;
        int ret = 0;
:
:                       
        if (d) {
                if (param->fp_get_lmv || param->fp_get_default_lmv) {
                        ret = cb_get_dirstripe(path, d, param);
                } else {
                        ret = ioctl(dirfd(d), LL_IOC_LOV_GETSTRIPE,
                                     (void *)&param->fp_lmd->lmd_lmm);

[Andreas Dilger]

Won't deprecate this interface for now.