Date: Fri, 6 May 2011 18:53:22 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: svn-src-head@freebsd.org, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <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: <20110506165322.GA1939@garage.freebsd.pl> In-Reply-To: <1136495405.1095168.1304682865076.JavaMail.root@erie.cs.uoguelph.ca> References: <20110506071351.GI14661@garage.freebsd.pl> <1136495405.1095168.1304682865076.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 06, 2011 at 07:54:25AM -0400, Rick Macklem wrote: > > 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. > >=20 > > 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. > >=20 > 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",...); >=20 > I'm not sure what happens when there are two modules both with the > same "fstype"? >=20 > 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? >=20 > 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?) >=20 > 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: >=20 > server1:/vol1 /vol1 nfs rw,nfsv4 0 0 > server2:/vol2 /vol2 nfs rw 0 0 > server3:/vol3 /vol3 nfs rw 0 0 >=20 > (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.) >=20 > 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. >=20 > 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: >=20 > server1:/vol1 /vol1 nfs rw,nfsv4 0 0 > server2:/vol2 /vol2 nfs rw 0 0 > server3:/vol3 /vol3 oldnfs rw 0 0 >=20 > 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. >=20 > 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. >=20 > 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. If you don't share my preference then it would be good to make new NFS just 'nfs' everywhere (sysctls, fstype, etc.), so that we won't end up with 'newnfs' in random places in five years from now. What you do with old NFS is less important to me:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk3EJ4IACgkQForvXbEpPzQF8ACfc3JfPKLLFjMAngEBud/n0IXF ISoAn1ROIXY+eNpNVAhI8bfnGKHwgZ1/ =g74i -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110506165322.GA1939>