[LU-14179] lfs find: error: llapi_semantic_traverse: string buffer too small

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.15.0
• Affects Version/s: Lustre 2.12.5
• Environment: CentOS 7.6 Lustre 2.12.5
• Severity: 4
• Assignee: Yang Sheng
• Reporter: Stephane Thiell

Description

Running a simple lfs find -i 11 /oak did generate a few of these messages today. I don't know exactly on which files sorry, just wanted to report it as you might be interested to investigate. It's with Lustre 2.12.5 client and server.

Comments

[Peter Jones]

Landed for 2.15

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/41337/
Subject: LU-14179 lfs: avoid lfs find error with long paths
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: a6a76df19db61a2015f4cc78f88060f249c955f2

[Gerrit Updater]

Stephane Thiell ([e-mail]) uploaded a new patch: https://review.whamcloud.com/41337
Subject: LU-14179 lfs: avoid lfs find error with long paths
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 72d703753eda6abe14e7ceae7d973ddeab65b22a

[Andreas Dilger]

Feel free to put that into a patch, ideally with a test case.

Fir the user's sake, they should probably fix their application to avoid creating a directory like that.

[Stephane Thiell]

Hi Andreas,

We hit this (minor) problem again on another directory tree when using lfs find. Like the first time, the root cause is clearly a bug in the user's application or script, as the path has a repetitive pattern in it. However, sometimes, surprisingly, we found valid files at the very end of the path, whose absolute paths are above 4096 bytes, so could be useful if lfs find does actually report all of them (eg. when we want to empty an OST and make sure no files are remaining on it). I tried your simple patch to avoid lfs find failure and I confirm it's working to get rid of the error.

Alternatively, one could decide that this error is actually valid and properly reported, and that these paths should be fixed first, as they are indeed too long for PATH_MAX. In that case, I think it would be nice to add the path of the directory to the error message, otherwise currently it's difficult to identify these long paths; something simple like this does seem to work for me:

@@ -2014,8 +2014,8 @@ static int llapi_semantic_traverse(char *path, int size, DIR *parent,
                path[len] = 0;
                if ((len + dent->d_reclen + 2) > size) {
                        llapi_err_noerrno(LLAPI_MSG_ERROR,
-                                         "error: %s: string buffer too small",
-                                         __func__);
+                                         "error: %s: string buffer too small for %s",
+                                         __func__, path);
                        break;
                }
                strcat(path, "/");

[Peter Jones]

Fine with me to reopen