https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-5315 Lustre <p>I hit this error when I run mkfs.lustre as before:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[root@centos6-1 tests]# LOAD=yes sh llmount.sh Loading modules from /root/master/lustre/tests/.. detected 2 online CPUs by sysfs Force libcfs to create 2 CPU partitions ../libcfs/libcfs/libcfs options: 'cpu_npartitions=2' debug=vfstrace rpctrace dlmtrace neterror ha config ioctl super lfsck subsystem_debug=all -lnet -lnd -pinger gss/krb5 is not supported quota/lquota options: 'hash_lqs_cur_bits=3' [root@centos6-1 tests]# ../utils/mkfs.lustre --mgs --fsname=lustre --mdt --index=0 --backfstype=ldiskfs --device-size=200000 --reformat /tmp/lustre-mdt1 mkfs.lustre FATAL: unhandled fs type 1 'ldiskfs' mkfs.lustre FATAL: unable to prepare backend (22) mkfs.lustre: exiting with 22 (Invalid argument) </pre> </div></div> <p>It happened because load_backfs_module(mount_type=LDD_MT_LDISKFS) failed in osd_init(). Running gdb showed</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">468 dirname = getenv(<span class="code-quote">"LUSTRE"</span>); (gdb) n 469 <span class="code-keyword">if</span> (dirname) { (gdb) p dirname $1 = 0x0 (gdb) n 507 <span class="code-keyword">return</span> NULL; </pre> </div></div> <p>Failed to use locally built modules.</p> <p>This code is from the patch <a href="http://review.whamcloud.com/#/c/10468" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/10468</a>. </p> LU-5315

mkfs.lustre FATAL: unhandled fs type 1 'ldiskfs'

Bug Minor Resolved Cannot Reproduce Emoly Liu Emoly Liu Thu, 10 Jul 2014 09:25:54 +0000 Fri, 1 Sep 2023 16:53:08 +0000 Fri, 28 Feb 2020 00:00:47 +0000 Lustre 2.6.0 0 6 <p>Nathaniel, I'm cooking the patch, but if you have a patch for that, please go ahead. Thanks.</p> <p>Probably the best fix is to use a relative path if mkfs.lustre (argv<span class="error">&#91;0&#93;</span>) is itself called with a relative path.</p> <p>The patch is at <a href="http://review.whamcloud.com/11063" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/11063</a> .</p> <p>Why not just set LUSTRE?</p> <p>LUSTRE is set by the test scripts via <tt>$(dirname $0)/..</tt> in most cases anyway, and this returns the functionality to what it was before we made mkfs.lustre require an external library to have basic functionality.</p> <p>Also, if LUSTRE is statically set in the user's environment, it will become incorrect (in a potentially hard to diagnose manner) if they are testing from different build trees, which is exactly the situation that developers who need this change will be in.</p> <p>Your comment about a static LUSTRE being set applies to current patch as well, since LUSTRE is evaluated first. Hopefully developers are using a test script (like llmount.sh) which should set LUSTRE correctly for them. For situations where the utilities are used directly, perhaps it would be better to specify the module directory with a command line option instead of LUSTRE should the developer need to override the default of $(dirname $0). If there is no need to override that default, then we probably don't need to evaluate $LUSTRE anymore. </p> <p>mount.lustre is always invoked from /sbin by mount and even relative path doesn't work for this situation. So I cook a patch to specify the mount plugin modules directory with a command line option, as Robert&amp;Ned Bass suggested.</p> <p>Since this new option will break some test scripts, I will upload the patch for a full test only first, and then request for review after it passes the test.</p> <p>Emoly,<br/> Is this issue still happening on Master?</p> <p>Jodi, yes, this problem is still happening on Master. Per Ned Bass' comment, the patch needs to be improved to use libtool to parse plugin path.</p> <p>Since I have been busy with CDH5 components study and testing these months, I didn't get a chance to improve this patch. I will keep working on it later.</p> <p>Close old bug that hasn't been seen in a long time.</p> Related LU-17079 Development Rank 1|hzwr27: Rank (Obsolete) 14851 Severity