[LU-4800] no automatic module load in newer kernels

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.6.0, Lustre 2.5.3
• Affects Version/s: Lustre 2.6.0, Lustre 2.5.1, Lustre 2.4.3
• Severity: 3
• Assignee: Bob Glossman (Inactive)
• Reporter: Bob Glossman (Inactive)

Description

This problem has been seen in several test environments with newer linux kernel versions than the 2.6.x or 3.0.x we currently support.
For lustre clients built against the unpatched, pristine kernel sources with default .config files I don't get lustre modules autoloading at mount time. example:

# mount -t lustre -o flock,user_xattr centos2:/lustre /mnt/lustre
mount.lustre: mount centos2:/lustre at /mnt/lustre failed: No such device
Are the lustre modules loaded?
Check /etc/modprobe.conf and /proc/filesystems

If I explicitly preload lustre modules with a modprobe command like "modprobe lustre" then the mount works fine.

I got the following commentary in email from Andreas:

This is a problem known to me. If the obdclass module is loaded, then it
will register the "lustre" filesystem type, so it will appear in
/proc/filesystems and mount will not modprobe the "lustre" filesystem
module.

This has been true since Lustre 1.6 or so (when "mountconf" was first
added).

Two options exist:

• modify the mount.lustre binary to always modprobe the "lustre" module if
  it isn't already loaded
• change the "lustre" filesystem type registration to be in the "lustre"
  module (as most other filesystems do). That has the problem that the
  servers do not need the "lustre.ko" module loaded, since that is really
  the client VFS interface. It would help if there was a second filesystem
  type "lustre_srv" or similar, that could be used to register server
  mountpoints, and possibly simplify the mount internals (which are
  convoluted because they have to do completely different things for client
  and server mounts).

Obviously, #1 is easier, but #2 would simplify the coe in the long term.

Issue Links

• is related to: LU-5186 code cleanups in module startups
• is related to: LU-12514 separate out the lustre mount code for server and clients
• is related to: LU-6013 Separate mount helpers for client and server
• is related to: LU-4416 support for 3.12 linux kernel

Comments

[Peter Jones]

Landed for 2.6

[James A Simmons]

Patch has landed to master. This ticket can be closed.

[Christopher Morrone (Inactive)]

I really like to see the clean Andreas and I did eventually gone in another time.

It would probably be best to start a new ticket to track that so it does not get lost.

[Bob Glossman (Inactive)]

I agree about following through on those cleanups. I plan to enter a new ticket for that. James, I will be sure to make you a Watcher there.

[James A Simmons]

With 2.6 so close to being released I'm happy if that lands. I really like to see the clean Andreas and I did eventually gone in another time. Sorry I got carried away with the idea of cleanup

[Bob Glossman (Inactive)]

Preliminary testing seems to confirm my theory. All that fancy handwaving both James and I did look unneeded. Please see my latest iteration at http://review.whamcloud.com/#/c/10587/6

[Bob Glossman (Inactive)]

Looking at both mine & James' mods I'm coming to the conclusion that there's a much simpler solution possible. Now investigating the possibility that the only essential feature is the added runtime request_module("lustre") in obd_mount.c. The improved error exit cleanups in init_lustre_lite are valuable and in fact I think init_obdclass needs similar fixes, but that isn't a necessary part of this mod. Should be followed up in another mod entirely (IMHO). James' symbol_get() calls may also be useful, but on the theory that simplest is best I'm seeing if they are really necessary.

If my latest theory is correct I will push a much simpler mod that does no relocation of the fs regiister/unregister calls at all.