[LU-14316] lfs: using old ioctl(LL_IOC_LOV_GETSTRIPE), use llapi_layout_get_by_path()

• Type: Bug
• Resolution: Unresolved
• Priority: Minor
• Severity: 3
• Assignee: WC Triage
• Reporter: Andreas Dilger

Description

The first time "lfs setstripe" is used after mount, there is always a message printed on the console:

Lustre: lfs: using old ioctl(LL_IOC_LOV_GETSTRIPE) on [0x200000402:0x2:0x0], use llapi_layout_get_by_path()

We shouldn't be using an old interface that prints a warning message for a standard command.

I haven't totally tracked down the callpath(s) that generate this message, but it is probably from the ll_file_getstripe() at the end of ll_lov_setstripe().

It may be enough to not print the message if size != 0, and pass the size of the ioctl buffer by getting it via _IOC_SIZE(cmd) when LL_IOC_LOV_GETSTRIPE_NEW is called, and start using LL_IOC_LOV_GETSTRIPE_NEW from lfs.c?

Issue Links

• is related to: LU-14337 return valid stripe_count and stripe_size instead of 0 for DoM files
• is related to: LU-12580 usercopy exposure attempt detected in LL_IOC_LOV_GETSTRIPE ioctl
• is related to: LU-11264 llapi_* routines demonstrate poor performance

Comments

[Gerrit Updater]

"Andreas Dilger <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/47053
Subject: LU-14316 llite: rename LL_IOC_LOV_GET,SETSTRIPE ioctls
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: cb2722a5cc36bf813aa9206a9e29a9cdce9e774f

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/43103/
Subject: LU-14316 llite: quiet spurious ioctl warning
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 4512bbc4567d9082a01db5d6a2e651054e086260

[Gerrit Updater]

Olaf Faaland-LLNL ([e-mail]) uploaded a new patch: https://review.whamcloud.com/43103
Subject: LU-14316 llite: quiet spurious ioctl warning
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: 2e1b067db71b3d75b635e988592b67b4835b3f2a

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/41427/
Subject: LU-14316 llite: quiet spurious ioctl warning
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: c6f65d8af116476d4fa62604a90b2e0d657b29b2

[Gerrit Updater]

Andreas Dilger ([e-mail]) uploaded a new patch: https://review.whamcloud.com/41427
Subject: LU-14316 llite: quiet spurious ioctl warning
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: fb9acd3f3598f84550f66efd2b4f38643bc5ca4e

[Gerrit Updater]

Andreas Dilger ([e-mail]) uploaded a new patch: https://review.whamcloud.com/41400
Subject: LU-14316 llite: quiet spurious ioctl warning
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0d61d6e47cb36e1a245f432090258709f067de90

[John Hammond]

> I haven't totally tracked down the callpath(s) that generate this message, but it is probably from the ll_file_getstripe() at the end of ll_lov_setstripe().

Correctamundo.

I think we should remove the message. Printing to the dmesg it is unlikely to have the intended effect on ADIO.

I'm not sure if I follow what you mean about _IOC_SIZE(cmd). For _IOC_SIZE(LL_IOC_LOV_GETSTRIPE) == sizeof(long) and _IOC_SIZE(LL_IOC_LOV_GETSTRIPE_NEW) == sizeof(struct lov_user_md).

Note that we should avoid naming new things BLAH_BLAH_NEW and call them BLAH_BLAH_v2 instead. (And definitely avoid renaming things from BLAH_BLAH to BLAH_BLAH_OLD.) We should also not depend on #defined types like lov_user_md when defining ioctls. Since if we change lov_user_md then the ioctl silently changes. (I'm not convinced that we would notice right away if we did that.) LL_IOC_LOV_GETSTRIPE_NEW should be defined using struct lov_used_md_v1 explicitly.

LL_IOC_LOV_GETSTRIPE_NEW and LL_IOC_LOV_SETSTRIPE_NEW are not used in our utilities. I don't think we have ever defined how large the buffer should actually be. We could just declare now that the buffer should be 65536 bytes.

One good simplification would be to stop calling ll_file_getstripe() at the end of ll_lov_setstripe(). I think we did this before and then undid it. Perhaps we could do this whenever LL_IOC_LOV_SETSTRIPE_NEW is used and switch lfs and llapi to using LL_IOC_LOV_SETSTRIPE_NEW.