[LU-1718] fix Lustre NFS re-export for 3.0+ kernels

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.3.0
• Fix Version/s: Lustre 2.4.0
• Type: Technical task
• Priority: Major
• Reporter: Andreas Dilger
• Assignee: WC Triage
• Resolution: Fixed

Description

During the LU-812 patch series to implement Linux 3.0 client support for Lustre, lustre_mount() was changed to remove the struct vfsmnt argument that was previously available to lustre_get_sb(). The lack of struct vfsmnt argument complicates the ability to re-export the Lustre client filesystem via NFS, due to the BUG_ON(!mnt) in dentry_open().

It seems rather unfortunate/unfair that the default get_name() function is passed the "mnt" argument, while the filesystem-specific get_name() is not. I don't know if this is due to technical or ideological reasons.

The simplest fix would would be to see if we can get a patch submitted upstream and to SLES SP3 to pass the "mnt" argument to the ->get_name() method, but this may hit objections and would take time in any case.

Another way to fix this, as btrfs_get_name() and gfs2_get_name() have done, is to implement the name lookup part of the code internally, without using the VFS readdir() code to do it. This is considerably more complex, since it would mean duplicating or refactoring ll_readdir(), ll_get_dir_page(), and ll_dir_readpage() to avoid the use of filp/file arguments so that it can be called directly from ll_get_name().

A major hack would be to stash the vfsmnt from some function like ll_getattr into sbi->ll_mnt, but this has the danger that the vfsmnt might change during runtime without Lustre being notified of it.

Issue Links

• is related to: LU-1646 mounting lustre oops on older kernels
• is related to: LU-812 Support for Linux 3.0 kernels

Comments

[Andreas Dilger]

Actual change introducing this problem is http://review.whamcloud.com/1951, since there are several patches landing under LU-812.

[James A Simmons]

I also thought about the hack of storing ll_mnt from some other function. Looking at the code it doesn't look to bad to refactor it much like btrfs and gfs2 does it. I have a patch I'm doing basic testing to right now that I can post soon.

[James A Simmons]

Okay this is a rough first patch, http://review.whamcloud.com/#change,3624. Most likely I missed some thing so feel free to tear it apart.

[James A Simmons]

Patch updated for master.

[James A Simmons]

I have a patch ready for NFS export testing for Lustre 2.1. The question is should http://review.whamcloud.com/#change,3661 be redone without the NFS disable part in llite_lib.c
and I submit my patch for this part or should I make my NFS patch dependent on the LU-812 patch for b2_1 as is?

[Bob Glossman (Inactive)]

James, I think you should make your NFS patch dependent on the LU-812 patch for b2_1 as is. As far as I can see your patch is only needed if and when http://review.whamcloud.com/#change,3661 is accepted and merged.

[Peter Jones]

Landed for 2.4

[James A Simmons]

Their is still a patch outstanding for b2_1

[Peter Jones]

James we track those differently