On Aug 27, 2009, at 10:14 AM, Steve Dickson wrote:
On 08/26/2009 03:59 PM, Trond Myklebust wrote:
On Wed, 2009-08-26 at 15:50 -0400, Chuck Lever wrote:
Yeah, switching file system types in the mount(2) system call is the
fly in the ointment. I'm just wondering if Trond had some thoughts
about making that more feasible.
Just look at what we're already doing for NFSv4. Inside
nfs4_get_sb, we
basically do a kernel mount in order to get the real super block. We
then simply have to attach it to the vfsmount that the sys_mount()
call
passed down to us.
Well its not nfs4_get_sb() that would have to change its nfs_get_sb()
that would have to do an nfs4 mount after it discovered the -o vers=4.
It would get very messy very quickly for absolutely no reason since
the propose mount patch is straightforward, it works and better yet
its done! ;-)
Right now we are only speculating that doing this in the kernel will
not be straightforward. You say it will be unbearably ugly, and Trond
says it should be simple. He said - he said. Why not try it and find
out?
I hear your point that you want this done for RHEL 6. I want IPv6
done for RHEL 6, but that's looking less and less likely. If this
were a RHEL-only proposal, I'd be all over it. But I'm concerned that
going with the mount command solution will make our lives more
challenging after RHEL 6 is come and gone. It seems to me that
upstream is less concerned with expediency and more concerned with
good long term solutions.
I'm going to ask around about this. If it really does look offensive
to people, or technically infeasible, or will take a ridiculously long
time to implement correctly, I'm OK with the mount command solution.
I think we can afford to investigate a little more if we can find a
solution that gets us farther down the road. All I'm asking for is a
little time to study the problem.
This really isn't anything new or difficult...
Granted, mounting from the kernel is not new, but giving sys_mount()
on file system type which ends up mounting a complete different
file system is new... Plus architecturally that just seems wrong...
A abit incestual... would you say! ;-)
I say we go with the proposed patch since its simple, architecturally
sound,
The whole point of text-based mounts is that we are supposed to be
building up the NFS mount stuff in the kernel, closer to where all the
client features are actually implemented, instead of in user space.
It doesn't make sense to add logic in the mount command while our long
term goal is to move it to the kernel, especially if we can find a
viable alternative kernel implementation.
will not cause problems down the road as long as nfs4 remains
a standalone file system and its done!
We know for _sure_ that at some point nfs4 will likely no longer be
visible to user space (or gone completely)... so that last point is
rather moot. Doing it in the mount command _will_ increase mount
command complexity down the road.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
