Must statd be running before nfs client makes mounts?
Subsystems (2)
I've just noticed that Debian mounts NFS filesystems from /etc/fstab before statd starts. Is this OK? (And I wonder at how it's going to try to do NFS client mounts before bind is even started, but I guess that's a separate issue... :-))
Signature · 11 lines
Chip Salzenberg - a.k.a. - <[email protected]> "It furthers one to have somewhere to go." ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 4 lines · On Sunday September 15, [email protected] wrote:
I've just noticed that Debian mounts NFS filesystems from
/etc/fstabbefore statd starts. Is this OK? (And I wonder at how it's going to try to do NFS client mounts before bind is even started, but I guess that's a separate issue... :-))
I think this is OK.
As long as statd starts before any lock requests are made, there certainly wont be any problems. And I think all the state management happens in the background with timeouts and re-trys so it shouldn't matter too much anyway (though if a process gets a lock, and the server restarts before the local statd starts, then you loose).
A related question is whether you should mount nfs directories before the nfs server is started.
If you have two machines that each mount a filesystem off the other, and they both do foreground mounts (the default) before the nfs server starts, then they will deadlock on boot.
I *think* (not having thought through it exhaustively) you should:
(start devices, raid, etc)
1/ mount local filesystems
(start network, bind, portmap)
2/ start nfsd if appropriate
3/ start statd
4/ mount nfs filesystems
It is possible that you need to treat some filesystems like /usr differently. On a data-less client, you probably need to mount /usr before starting some of the network stuff like bind or portmap. These would typically be mounted with nolocks so there are no issues with starting statd later, and there shouldn't be cross-mounting issues in this situations. So maybe you need a
1a/ mount /var and /usr if they are nfs.
You really want a generic way of distinguishing which mounts are needed early... pity mount won't let you select on "dump" or "pass" fields (will it).
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 4 lines · Neil Brown
(start devices, raid, etc)
1/ mount local filesystems
(start network, bind, portmap)
I am thinking to write a kernel patch to set nlm_udpport and nlm_tcpport. The current scheme works only with module and /proc won't work with module. I'd like to be able to set ports used by lockd according to /etc/services. In my case, I have
nlockmgr 3003/tcp
nlockmgr 3003/udp
But I have to hard code them in my kernel.
Quoted 4 lines
2/ start nfsd if appropriate
3/ start statd
4/ mount nfs filesystems
H.J.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 11 lines · On Sunday September 15, [email protected] wrote:
Quoted 4 lines · Neil Brown
(start devices, raid, etc)
1/ mount local filesystems
(start network, bind, portmap)I am thinking to write a kernel patch to set
nlm_udpportandnlm_tcpport. The current scheme works only with module and /proc won't work with module. I'd like to be able to set ports used by lockd according to/etc/services. In my case, I have
Quoted 4 lines
nlockmgr 3003/tcp
nlockmgr 3003/udpBut I have to hard code them in my kernel.
You shouldn't need to hard code them, kernel parameters:
lockd.udpport=3003 lockd.tcpport=3003
should work fine (unless that is what you mean by hardcoding)
However I don't see a problem with doing this via a sysctl, quite possibly a sysctl under /proc/sys/sunrpc/ (as it is an RPC service).
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 12 lines · Neil Brown
Quoted 11 lines · On Sunday September 15, [email protected] wrote:
Quoted 4 lines · Neil Brown
(start devices, raid, etc)
1/ mount local filesystems
(start network, bind, portmap)I am thinking to write a kernel patch to set
nlm_udpportandnlm_tcpport. The current scheme works only with module and /proc won't work with module. I'd like to be able to set ports used by lockd according to/etc/services. In my case, I have
Quoted 8 lines
Quoted 4 lines
nlockmgr 3003/tcp
nlockmgr 3003/udpBut I have to hard code them in my kernel.
You shouldn't need to hard code them, kernel parameters:
lockd.udpport=3003 lockd.tcpport=3003should work fine (unless that is what you mean by hardcoding)
It is still hardcoding since can't change it at runtime.
Quoted 4 lines
However I don't see a problem with doing this via a sysctl, quite possibly a sysctl under
/proc/sys/sunrpc/(as it is an RPC service).
Does it work with sunrpc as module?
H.J.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 7 lines · On Monday September 16, [email protected] wrote:
Quoted 4 lines
However I don't see a problem with doing this via a sysctl, quite possibly a sysctl under
/proc/sys/sunrpc/(as it is an RPC service).Does it work with sunrpc as module?
Well.....
modprobe lockd
echo 3033 > /proc/sys/sunrpc/lockd/udp_port
echo 3033 > /proc/sys/sunrpc/lockd/tcp_port
should work.
It wouldn't work for module auto-loading, but if you wanted that you could use the currently available module parameters.
Certainly it would be nice to have a single mechanism that always worked, but I don't think the kernel infrastructure is up to that at the moment. Rusty Russel was talking at the Kernel Summit about unifying kernel parameters, module parameters and some /proc like thing (where it be sysctl or /proc or driverfs or....). It would be good but it isn't there yet.
That said, it would probably be possible to arrange auto-loading to trigger off /proc/sys access... I'm keen to do away with the nfsd system call altogether.
echo 32 > /proc/sys/sunrpc/nfsd/nthreads
starts the server,
echo 0 > /proc/sys/sunrpc/nfsd/nthreads
stops it.
However this is only a vague idea as yet.
NeilBrown
-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 3 lines · Neil Brown
Certainly it would be nice to have a single mechanism that always worked, but I don't think the kernel infrastructure is up to that at
Well, nfssvc(port, count) works for all. Why can't lockdport (tcp, udp)?
H.J.
-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs