[LU-5315] mkfs.lustre FATAL: unhandled fs type 1 'ldiskfs'

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.6.0
• Type: Bug
• Priority: Minor
• Reporter: Emoly Liu
• Assignee: Emoly Liu
• Resolution: Cannot Reproduce
• Severity: 3

Description

I hit this error when I run mkfs.lustre as before:

[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)

It happened because load_backfs_module(mount_type=LDD_MT_LDISKFS) failed in osd_init(). Running gdb showed

468			dirname = getenv("LUSTRE");
(gdb) n
469			if (dirname) {
(gdb) p dirname
$1 = 0x0
(gdb) n
507			return NULL;

Failed to use locally built modules.

This code is from the patch http://review.whamcloud.com/#/c/10468.

Issue Links

• is related to: LU-17079 Refactor mkfs/mount plugin system

Comments

[Emoly Liu]

Nathaniel, I'm cooking the patch, but if you have a patch for that, please go ahead. Thanks.

[Andreas Dilger]

Probably the best fix is to use a relative path if mkfs.lustre (argv[0]) is itself called with a relative path.

[Emoly Liu]

The patch is at http://review.whamcloud.com/11063 .

[Robert Read (Inactive)]

Why not just set LUSTRE?

[Andreas Dilger]

LUSTRE is set by the test scripts via $(dirname $0)/.. 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.

[Andreas Dilger]

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.

[Robert Read (Inactive)]

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.

[Emoly Liu]

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&Ned Bass suggested.

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.

[Jodi Levi (Inactive)]

Emoly,
Is this issue still happening on Master?

[Emoly Liu]

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.

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.

[Andreas Dilger]

Close old bug that hasn't been seen in a long time.