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... :-))
--
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
On Sunday September 15, [email protected] wrote:
> 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... :-))
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
On Mon, Sep 16, 2002 at 09:26:21AM +1000, Neil Brown wrote:
>
> (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.
> 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
On Sunday September 15, [email protected] wrote:
> On Mon, Sep 16, 2002 at 09:26:21AM +1000, Neil Brown wrote:
> >
> > (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.
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
On Mon, Sep 16, 2002 at 10:00:11AM +1000, Neil Brown wrote:
> On Sunday September 15, [email protected] wrote:
> > On Mon, Sep 16, 2002 at 09:26:21AM +1000, Neil Brown wrote:
> > >
> > > (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.
>
> 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)
It is still hardcoding since can't change it at runtime.
>
> 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
On Monday September 16, [email protected] wrote:
> >
> > 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
On Tue, Sep 17, 2002 at 09:26:02AM +1000, Neil Brown wrote:
>
> 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