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
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/mntnfsrw 00 nfs-server:/sub2/mnt2 oldnfs rw 00 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. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpvKMQMMwzuD.pgp Description: PGP signature
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
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,nfsv40 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,nfsv40 0 server2:/vol2 /vol2 nfs rw 0 0 server3:/vol3 /vol3 oldnfs rw0 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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Pawel Jakub Dawidek p...@freebsd.org writes: 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. Precisely what I was trying to say. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
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. 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,nfsv40 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,nfsv40 0 server2:/vol2 /vol2 nfs rw 0 0 server3:/vol3 /vol3 oldnfs rw0 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. 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:) -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpBLcdbFNGSn.pgp Description: PGP signature
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
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:) As you'll see from the post I just sent (about 5sec before this showed up in my box), I don't mind the idea of the two clients not being concurrently usable. (I did have that semi-hypothetical example, but I, personally, don't think it's likely. I had assumed that others would think this is required, but if not, that's fine with me.) My problem is that I don't know how to deal with two modules with the same name. (Getting rid of the old one as a module and making people have to compile it into their kernel solves that.) If both still need to be loadable modules, I think I'm going to need some help w.r.t. how to make that work. (The mount syscall tries to load it. The /etc/rc.d/nfsclient script forces it to be loaded and who knows what else. If there are two of them, then???) rick ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Pawel Jakub Dawidek p...@freebsd.org writes: 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. Precisely what I was trying to say. Well, if running the two clients concurrently isn't a requirement, how does this sound? - Get rid of the module building for the old client. (ie. delete sys/modules/nfsclient) That way there is only one client NFS module to load and there isn't any confusion over which one to load and when. -- then, if anyone wants/needs the old client, they would have to build a kernel with options NFSCLIENT specified. (This wouldn't really affect the diskless NFS root folks, since they have to compile a client into the kernel anyhow. If no client is compiled into the kernel, the new one would be loaded as a module. I kinda like this variation because: 1 - It's simple and I know how to do it. (I don't know how to handle things like kern_modload() calls inside the mount(2) syscall when there are 2 client modules both having fstype nfs, etc and so forth.) 2 - It deprecates the old client, so anyone using it will know that they are and most won't switch to the old unless they really need to. The downside is that anyone wanting/needing to switch to the old client will have to recompile a kernel to do so. So, does this sound ok? rick ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: My problem is that I don't know how to deal with two modules with the same name. Why do they have to have the same name? All that matters is the fstype and the sysctls. Just make sure that the auto-load logic loads the new stack and not the old one if neither is loaded already. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: My problem is that I don't know how to deal with two modules with the same name. Why do they have to have the same name? All that matters is the fstype and the sysctls. Just make sure that the auto-load logic loads the new stack and not the old one if neither is loaded already. Well, the main auto-load logic is the (n)mount(2) syscall and it does a vfs_byname_kld(fstype, td, errp), which calls kern_kldload(td, fstype, fileid) to load the module. The argument is the fstype, so that is what is used to find/load the module. The way sys/nfsclient is set up (and I think this is the norm for file systems), the module name is the fstype name, because VFS_SET(nfs_vfsops, oldnfs, VFCF_NETWORK); (There is a DECLARE_MODULE() in this macro and it uses the 2nd arg. to set the module name, same as the fstype name. Just take a look at the VFS_SET() macro in sys/mount.h.) defines the module name as the 2nd argument, which is also the fstype. (You can give it another name via DECLARE_MODULE(), although I'm not sure if that it considered correct to do, but it will be the fstype that the mount(2) syscall will use to try and load it.) rick ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
So, how about % cd /usr/src/sys % svn rm nfsclient ? :) DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: Dag-Erling Smørgrav d...@des.no writes: Ideally, both the old and the new NFS stack would use the same fstypes and sysctl names, but I don't know if there's any way we can prevent someone from compiling both into the kernel at the same time, or loading both modules. If the scripts in /etc/rc.d are fixed to use the correct sysctl naming, do you think it matters which one is vfs.nfs.? Yes. There is a whole world outside the base system: munin, webmin, nagios etc. Are you going to change all of them as well? DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: Dag-Erling Smørgrav d...@des.no writes: Ideally, both the old and the new NFS stack would use the same fstypes and sysctl names, but I don't know if there's any way we can prevent someone from compiling both into the kernel at the same time, or loading both modules. If the scripts in /etc/rc.d are fixed to use the correct sysctl naming, do you think it matters which one is vfs.nfs.? Yes. There is a whole world outside the base system: munin, webmin, nagios etc. Are you going to change all of them as well? Well, another way it could be handled would be to put the sysctls and the global variables they manipulate in a module shared by both clients, like sys/nfs/nfs_lock.c (module nfslock). Then the same sysctl would affect both clients. (I hesitate to create yet another module just to share the sysctls, but since nfslock is used by both clients, it should work ok, I think.) What do you think of that? If anyone else reading this has an idea/opinion, please let us know. rick ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: Well, another way it could be handled would be to put the sysctls and the global variables they manipulate in a module shared by both clients, like sys/nfs/nfs_lock.c (module nfslock). Then the same sysctl would affect both clients. (I hesitate to create yet another module just to share the sysctls, but since nfslock is used by both clients, it should work ok, I think.) I don't understand why you would want to do that. Can't you just change oldnfs back to nfs in the old stack? Hmm, it occurred to me that there is currently no way to tell the kernel that two drivers conflict with eachother. Perhaps I should take a shot at implementing a DRIVER_CONFLICT macro to mirror DRIVER_DEPEND. BTW, don't take this personally, I'm very grateful for (and impressed with) your NFS work, other than this little nit :) DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: Well, another way it could be handled would be to put the sysctls and the global variables they manipulate in a module shared by both clients, like sys/nfs/nfs_lock.c (module nfslock). Then the same sysctl would affect both clients. (I hesitate to create yet another module just to share the sysctls, but since nfslock is used by both clients, it should work ok, I think.) I don't understand why you would want to do that. Can't you just change oldnfs back to nfs in the old stack? I'm not sure what you are saying. W.r.t. the SYSCTL() naming, the old NFS client is currently using vfs.nfs.xxx and the new NFS client is using vfs.newnfs.xxx. If you are referring to the fstype names, then switching oldnfs back to nfs means the new one has to change to something other than nfs, like newnfs. The whole idea of changing newnfs-nfs was to make it the default and get it more widely tested/used. (Presumably, if the new NFS works well, it would eventually become the only one, but I don't see that happening until FreeBSD10 at the earliest.) The problem is w.r.t. the SYSCTL() naming. I could make vfs.newnfs.xxx use vfs.nfs.xxx and vfs.nfs.xxx-vfs.oldnfs.xxx quite easily. The problem would be that people couldn't as easily use oldnfs instead of nfs. (At least for cases where setting sysctls matter.) What I was proposing is have the two clients share the vfs.nfs.xxx name space, since most of the SYSCTL()s use the same name and do the same thing. For example, now there is: vfs.nfs.bufpackets: 4 vfs.newnfs.bufpackets: 4 and /etc/rc.d/nfsclient wants to fiddle with vfs.nfs.bufpackets. I was proposing that the two clients share vfs.nfs.bufpackets Make sense now? (I understood that you felt having both vfs.nfs.xxx and vfs.newnfs.xxx made maintaining the scripts awkward.) rick ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: Well, another way it could be handled would be to put the sysctls and the global variables they manipulate in a module shared by both clients, like sys/nfs/nfs_lock.c (module nfslock). Then the same sysctl would affect both clients. (I hesitate to create yet another module just to share the sysctls, but since nfslock is used by both clients, it should work ok, I think.) I don't understand why you would want to do that. Can't you just change oldnfs back to nfs in the old stack? Hmm, it occurred to me that there is currently no way to tell the kernel that two drivers conflict with eachother. Perhaps I should take a shot at implementing a DRIVER_CONFLICT macro to mirror DRIVER_DEPEND. 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/mntnfsrw 00 nfs-server:/sub2/mnt2 oldnfs rw 00 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. rick ps: The issue you pointed out in the first post is just a line in /etc/rc.d/mountcritremote that needs to be fixed. It uses a module name of nfs and nfsclient when the new NFS is nfs and nfscl (the old one is oldnfs and nfsclient). That's easy to fix. I'm just waiting for a review. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: Dag-Erling Smørgrav d...@des.no writes: Ideally, both the old and the new NFS stack would use the same fstypes and sysctl names, but I don't know if there's any way we can prevent someone from compiling both into the kernel at the same time, or loading both modules. If the scripts in /etc/rc.d are fixed to use the correct sysctl naming, do you think it matters which one is vfs.nfs.? Yes. There is a whole world outside the base system: munin, webmin, nagios etc. Are you going to change all of them as well? Btw, the simpler patch is to just change the SYSCTL() naming conventions, but there is no easy way (at least with recompiling the kernel + modules) to switch it back so the old client uses vfs.nfs.xxx. In other words: vfs.nfs.xxx - would be the variables on the new client vfs.oldnfs.xxx - would be the same variables for the old client Then the default/new client would work, but switching back to the old would be involved. With the SYSCTL() name space shared, the switch back and forth would be simply which fstype was used for the mounts and they would both see the same sysctl changes. rick ps: I have the shared patch running here now. It is straightforward, but fairly big. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: Dag-Erling Smørgrav d...@des.no writes: Are you going to rename the sysctls as well? I was not planning on it, but it the collective thinks it's a good idea, I could do so. Yes, please. The change from vfs.nfs to vfs.newnfs breaks scripts. Ideally, both the old and the new NFS stack would use the same fstypes and sysctl names, but I don't know if there's any way we can prevent someone from compiling both into the kernel at the same time, or loading both modules. If the scripts in /etc/rc.d are fixed to use the correct sysctl naming, do you think it matters which one is vfs.nfs.? rick ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@freebsd.org writes: Log: This patch changes head so that the default NFS client is now the new NFS client (which I guess is no longer experimental). The fstype newnfs is now nfs and the regular/old NFS client is now fstype oldnfs. Are you going to rename the sysctls as well? I was not planning on it, but it the collective thinks it's a good idea, I could do so. For the new NFS, the sysctls all live under vfs.newnfs (a lot of the code is shared between client and server, so it would be difficult to separate them out). Ones that are common with the old NFS use the same names, but there are also a bunch of new ones that have different names. rick ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@uoguelph.ca writes: Dag-Erling Smørgrav d...@des.no writes: Are you going to rename the sysctls as well? I was not planning on it, but it the collective thinks it's a good idea, I could do so. Yes, please. The change from vfs.nfs to vfs.newnfs breaks scripts. Ideally, both the old and the new NFS stack would use the same fstypes and sysctl names, but I don't know if there's any way we can prevent someone from compiling both into the kernel at the same time, or loading both modules. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
Rick Macklem rmack...@freebsd.org writes: Log: This patch changes head so that the default NFS client is now the new NFS client (which I guess is no longer experimental). The fstype newnfs is now nfs and the regular/old NFS client is now fstype oldnfs. Are you going to rename the sysctls as well? DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
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
On Apr 27, 2011, at 5:51 PM, Rick Macklem wrote: Author: rmacklem Date: Wed Apr 27 17:51:51 2011 New Revision: 221124 URL: http://svn.freebsd.org/changeset/base/221124 Log: This patch changes head so that the default NFS client is now the new NFS client (which I guess is no longer experimental). The fstype newnfs is now nfs and the regular/old NFS client is now fstype oldnfs. Wooohooo! Thanks a lot for all the hard work! :) Bjoern -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
