[lustre-discuss] lustre-2.15.8 at Debian

Tue Jul 14 12:06:34 UTC 2026

Hello,

This is easy to fix. The problem was due to the new gcc compiler checks the
potentially buffer overflow condition of snprintf() more strictly. From the
error message you provided, the problem occurred in

lustre-2.15.8/lnet/utils/lnetconfig/liblnetconfig.c, line 92.

Please just use an editor to open that file, scroll to line 92. Around
there, please change the whole subroutine open_sysfs_file() to the
following:

================================================================================
int open_sysfs_file(const char *path, const char *attr, const int mode)
{
        int fd;
        char filename[LNET_MAX_STR_LEN];

        if (snprintf(filename, sizeof(filename), "%s%s", path, attr) >=
            sizeof(filename))
                return -1;

        fd = open(filename, mode);

        return fd;
}
================================================================================

As you can see, we just make a slight rearrangement of snprintf(), and the
if condition.

There are several places to do the similar change. After doing this,
Lustre-2.15.8 can be compiled.

For your other question, whether it is OK to use Lustre-2.17.0 or 2.15.8 is
safer ?

Well, for my test, Lustre-2.17.0 works well in most cases (we have another
cluster using 2.17.0), but has some serious problems in the system
maintenance aspect. In case I want to move all data from one of an OST,
probably due to the OST is going to be replaced, I have to use the
following command to figure out all the files located in that OST, and then
do the data movement:

lfs find --obd fsname-OSTXXXX_UUID /mount/point > file_list.txt

This step caused the loading of the MDT server to blow up and then crash. I
am not quite sure where the problem is. I used ZFS-2.3.6 as the backend
file system for both MDT and OST. The problem may either be due to ZFS or
Lustre, I am not sure. Fortunately this maintenance task is rarely used. So
I just let it run, and it has run for about half a year without any other
problems. I am waiting for the next release of Lustre-2.17.X and see
whether this problem can be solved.

On the other hand, is Lustre-2.15.8 completely OK without any problems ?
Well, not really. We encountered a user who wants to run a special job,
which needs to randomly seek and read a lot of pieces of data fragments
from a very large image very quickly, which always failed in Lustre-2.15.8
with ZFS-2.1.5 backend (both MDT and OST). To fix this problem, we are
forced to try Lustre-2.17.0 with ZFS-2.3.6 backend, and it did solve the
problem.

So, my suggestion is, if Lustre-2.15.8 can work for all your normal tasks,
you may use it, otherwise you may try Lustre-2.17.0. I maintain a lot of
clustres, only one of them uses Lustre-2.17.0, and all the others use
Lustre-2.15.X. They all work well in our daily tasks for years, except the
situations I mentioned above.

Best,
T.H.Hsieh

Greg via lustre-discuss <lustre-discuss at lists.lustre.org> 於 2026年7月12日週日
下午6:33寫道：

> Thanks to all for your answers.
>
> Good news is that I was able to build lustre-2.17.0 client against both:
>
> Debian 12 Bookworm linux-image-6.1.0-50-amd64
> Debian 13 Trixie linux-image-6.12.95+deb13-amd64
>
> using the following:
>
> git clone "https://review.whamcloud.com/fs/lustre-release" \
> /lustre-2.17.0
> cd /lustre-2.17.0/
> git checkout 2.17.0
> ./autogen.sh
> ./configure --with-linux=/usr/src/linux-headers-6.12.95+deb13-amd64/ \
> --with-o2ib=no --disable-server
> make dkms-debs
>
> _but_
>
> Whatever I do compiling 2.15.8 I end up with the following:
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../..
> -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -DLUSTRE_UTILS=1
> -I/usr/include/libnl3 -fPIC -include /lustre-2.15.8/undef.h -include
> /lustre-2.15.8/config.h -I/lustre-2.15.8/lnet/include/uapi
> -I/lustre-2.15.8/lustre/include/uapi -I/lustre-2.15.8/libcfs/include
> -I/lustre-2.15.8/lnet/utils/ -I/lustre-2.15.8/lustre/include -g -O2
> -Wall -Werror -c liblnetconfig.c  -fPIC -DPIC -o
> .libs/liblnetconfig_la-liblnetconfig.o
> liblnetconfig.c: In function 'open_sysfs_file':
> liblnetconfig.c:92:49: error: '%s' directive output may be truncated
> writing up to 127 bytes into a region of size between 1 and 128
> [-Werror=format-truncation=]
>     92 |         snprintf(filename, sizeof(filename), "%s%s",
>        |                                                 ^~
> liblnetconfig.c:92:9: note: 'snprintf' output between 1 and 255 bytes
> into a destination of size 128
>     92 |         snprintf(filename, sizeof(filename), "%s%s",
>        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     93 |                  path, attr);
>        |                  ~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> So, the question is: is it safe to use 2.17.0 client against 2.15.8 server?
>
> --
> Regards
> Greg
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss_lists.lustre.org/attachments/20260714/8c9eb205/attachment.html>