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

Related — Tue, 4 Dec 2012 15:04:30 +0000

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.

Whamcloud Community JIRA

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