On Thu, Aug 27, 2009 at 01:32:09PM -0400, Chuck Lever wrote:
>>>> 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?
It's actually trivial. The file_system_type does not have much meaning
at all, it contains very little information:
- the implementation module - this is obviously the same for nfs and
nfs4
- the name - we actually want nfs for v4 here, that's the point.
- the get_sb method - we want to call the v4 method after initial
option parsing. This is totally trivial if done as a quick hack,
but some refactoring to share code might be a better idea
- the kill_sb method - we just need a flag to chose which one.
Again a bit of refactoring there might not be a bad idea here either:
e.g. why does nfs_kill_super do a bdi_unregister but nfs4_kill_super
not.
- the flags in fs_flags - fortunately the same for nfs and nfs4.
- a list entry for the list of register filesystems. That list is not
used much:
- for printing the list of filesystems in /proc/filesystems
- for finding the filesystem by name using get_fs_type, mostly
for mounting
- for the whacko sysfs system call needing an index into this
list.
So doing this really is easy. And if done properly it might actually
clean the code up, too.
>
> 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
>
>
>
> _______________________________________________
> NFSv4 mailing list
> NFSv4@xxxxxxxxxxxxx
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
---end quoted text---
--
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
