Date: Fri, 6 May 2011 07:54:25 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: svn-src-head@freebsd.org, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>, svn-src-all@freebsd.org, src-committers@freebsd.org, Rick Macklem <rmacklem@FreeBSD.org> Subject: Re: svn commit: r221124 - in head: . sbin/mount sbin/mount_nfs sys/amd64/conf sys/fs/nfsclient sys/i386/conf sys/ia64/conf sys/nfsclient sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf Message-ID: <1136495405.1095168.1304682865076.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110506071351.GI14661@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, May 05, 2011 at 07:06:46PM -0400, Rick Macklem wrote:
> > Also, except for the SYSCTL() naming issue they don't comflict. At
> > the
> > moment it is perfectly ok to use both for mounts concurrently.
> > For example, you could have the following 2 lines in your
> > /etc/fstab:
> >
> > nfs-server:/sub1 /mnt nfs rw 0 0
> > nfs-server:/sub2 /mnt2 oldnfs rw 0 0
> >
> > I don't know why you would actually choose to do this, unless you
> > found
> > that the old NFS client did something that worked better for "/sub2"
> > for
> > your purposes, but it will work fine.
>
> My personal opinion is that supporting such configuration is not worth
> the efforts and actually I'd prefer to use the same sysctl tree
> (vfs.nfs.*) and the same fstype (nfs) in both clients. User would
> decide
> which to use by loading one kernel module or the other.
>
Well, first off, I think there are problems if you have two modules
using the same "fstype" name. For example, the old mount syscall
which is still used by amd, does an unconditional
kern_kldload(.., "fstype",...);
I'm not sure what happens when there are two modules both with the
same "fstype"?
Also, there could be a script in /etc/rc.d that runs before any mount is
attempted (I don't know how to do this, but I assume rc@ will) and it
could load one or the other based on an rc.conf variable, but what
about doing a mount from single user?
And I also don't know how to tell the system to allow kernels to be
built with one of NFSCLIENT, NFSCL, but not both of them? (It would
fail for both of them, since there would be 2 VFS_SET()s with the
same "fstype", I think?)
I also think there might be situations where running both concurrently
could still be useful (that's the way things have been for 8.n).
Here's a not too hypothetical example:
- an 8.n system mounts 3 file servers
server1 - a FreeBSD server with NFSv4 enabled
server2 - Solaris8
server3 - some Linux distro
and the /etc/fstab entries look like:
server1:/vol1 /vol1 nfs rw,nfsv4 0 0
server2:/vol2 /vol2 nfs rw 0 0
server3:/vol3 /vol3 nfs rw 0 0
(The part w.r.t. server1 using NFSv4 isn't too hypothetical, since I
recently got email from a guy who is using NFSv4 on 8.2 because it
fixed a file locking problem for him. Related to openoffice, if I
recall correctly.)
The above is using both NFS clients concurrently, although whoever
set it up might not realize that, since server1 using "newnfs" because
that's needed for NFSv4.
Ok, now this system is upgraded to 9.0 and then /vol3 goes wonky.
If both clients can still run concurrently, /etc/fstab could be changed
to:
server1:/vol1 /vol1 nfs rw,nfsv4 0 0
server2:/vol2 /vol2 nfs rw 0 0
server3:/vol3 /vol3 oldnfs rw 0 0
to seee if the problem is caused by the switchover to the new NFS
client. If the wonkyness goes away, I have some work to do. If not,
I'm off the hook because something else is causing the wonkyness.
If the two stacks can't run concurrently, the above change couldn't
be done, because "nfsv4" isn't supported by the old NFS client.
In summary, at this point, changing the vfs.nfs.xxx to be shared
by the two clients is, to me, easier than trying to change things
so the two clients use the same "fstype" and can't run concurrently
and I also think there may be cases where running them concurrently
in 9.0 would be useful.
rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1136495405.1095168.1304682865076.JavaMail.root>