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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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,
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
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
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
21 matches
Mail list logo
