<div dir="ltr"><div>Hello,</div><div><br></div><div>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</div><div><br></div><div>lustre-2.15.8/lnet/utils/lnetconfig/liblnetconfig.c, line 92.</div><div><br></div><div>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:</div><div><br></div><div>================================================================================<br></div><div>int open_sysfs_file(const char *path, const char *attr, const int mode)<br>{<br> int fd;<br> char filename[LNET_MAX_STR_LEN];<br><br> if (snprintf(filename, sizeof(filename), "%s%s", path, attr) >=<br> sizeof(filename))<br> return -1;<br><br> fd = open(filename, mode);<br><br> return fd;<br>}</div><div>================================================================================</div><div><br></div><div>As you can see, we just make a slight rearrangement of snprintf(), and the if condition.</div><div><br></div><div>There are several places to do the similar change. After doing this, Lustre-2.15.8 can be compiled.</div><div><br></div><div>For your other question, whether it is OK to use Lustre-2.17.0 or 2.15.8 is safer ?</div><div><br></div><div>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:</div><div><br></div><div>lfs find --obd fsname-OSTXXXX_UUID /mount/point > file_list.txt</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>T.H.Hsieh</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Greg via lustre-discuss <<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.org</a>> \u65bc 2026\u5e747\u670812\u65e5\u9031\u65e5 \u4e0b\u53486:33\u5beb\u9053\uff1a<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks to all for your answers.<br>
<br>
Good news is that I was able to build lustre-2.17.0 client against both:<br>
<br>
Debian 12 Bookworm linux-image-6.1.0-50-amd64<br>
Debian 13 Trixie linux-image-6.12.95+deb13-amd64<br>
<br>
using the following:<br>
<br>
git clone "<a href="https://review.whamcloud.com/fs/lustre-release" rel="noreferrer" target="_blank">https://review.whamcloud.com/fs/lustre-release</a>" \<br>
/lustre-2.17.0<br>
cd /lustre-2.17.0/<br>
git checkout 2.17.0<br>
./autogen.sh<br>
./configure --with-linux=/usr/src/linux-headers-6.12.95+deb13-amd64/ \<br>
--with-o2ib=no --disable-server<br>
make dkms-debs<br>
<br>
_but_<br>
<br>
Whatever I do compiling 2.15.8 I end up with the following:<br>
<br>
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../.. <br>
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -DLUSTRE_UTILS=1 <br>
-I/usr/include/libnl3 -fPIC -include /lustre-2.15.8/undef.h -include <br>
/lustre-2.15.8/config.h -I/lustre-2.15.8/lnet/include/uapi <br>
-I/lustre-2.15.8/lustre/include/uapi -I/lustre-2.15.8/libcfs/include <br>
-I/lustre-2.15.8/lnet/utils/ -I/lustre-2.15.8/lustre/include -g -O2 <br>
-Wall -Werror -c liblnetconfig.c -fPIC -DPIC -o <br>
.libs/liblnetconfig_la-liblnetconfig.o<br>
liblnetconfig.c: In function 'open_sysfs_file':<br>
liblnetconfig.c:92:49: error: '%s' directive output may be truncated <br>
writing up to 127 bytes into a region of size between 1 and 128 <br>
[-Werror=format-truncation=]<br>
92 | snprintf(filename, sizeof(filename), "%s%s",<br>
| ^~<br>
liblnetconfig.c:92:9: note: 'snprintf' output between 1 and 255 bytes <br>
into a destination of size 128<br>
92 | snprintf(filename, sizeof(filename), "%s%s",<br>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
93 | path, attr);<br>
| ~~~~~~~~~~~<br>
cc1: all warnings being treated as errors<br>
<br>
So, the question is: is it safe to use 2.17.0 client against 2.15.8 server?<br>
<br>
-- <br>
Regards<br>
Greg<br>
_______________________________________________<br>
lustre-discuss mailing list<br>
<a href="mailto:lustre-discuss@lists.lustre.org" target="_blank">lustre-discuss@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org</a><br>
</blockquote></div>