On Monday July 16, [email protected] wrote:
> On Mon, Jul 16, 2007 at 11:13:14AM +1000, Neil Brown wrote:
> > Is this simply because you were mounting NFS filesystems before
> > running statd? In that case, maybe we should say that it "highlighted
> > that your NFS mounting on boot was already broken" ?? :-)
>
> Yes, we were. I'm in the process of patching the boot process now, so you
> could probably shed light on a related issue: Do we need to start portmap
> before statd or not? The comments in the old code is slightly cryptic :-)
Yes. Portmap should be one of the first things started after basic
networking is up. You might even be able to start it before that, but
I'm not sure. You need it before any RPC service which includes
statd, lockd, nfsd, ypbind, ...
You can mount an NFS filesystem with '-o nolocks' before portmap, but
that it about all.
>
> >> Also, it seems to be less forgiving about portmapper
> >> registration; cfs (an encrypted filesystem based off NFS, it seems) sets
> >> up a server on port 3049 and expects "-o port=3049,nfsvers=2" to work. The
> >> new mount.nfs searches for a portmapper unless the udp option is also
> >> correctly set.
> > I'm a bit confused here. I would expect that to avoid portmap being
> > used, you would need to set both 'port' and 'mountport' on the command
> > line. It shouldn't have anything to do with whether UDP is set. Can
> > you say a bit more about what you discovered here?
>
> Well, I have no idea how these things work at all, I just traced through the
> code and saw what would make it work :-) cfs runs as its own NFS daemon, on
> port 3049, but does not seem to register with the portmapper. The mount
> command given, without "-o udp", gives:
>
> mount: mount to NFS server 'localhost' failed: RPC Error: Success.
>
> The error seems to originate from probe_nfsport(), which also has a line
> saying
>
> if (pmap->pm_vers && pmap->pm_prot && pmap->pm_port)
> return 1;
>
> which indicates that if version+protocol+port are all set beforehand, don't
> probe -- and indeed, that works. I stopped debugging the issue there.
Hmmm.... That code looks a little odd. If you say you want udp, it
will still probe for tcp first. That doesn't hurt as UDP and TCP
always use the same port: 2049. But it is still odd. I wonder if it
is needed at all.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Jul 16, 2007 at 08:15:19PM +1000, Neil Brown wrote:
> Hmmm.... That code looks a little odd. If you say you want udp, it
> will still probe for tcp first. That doesn't hurt as UDP and TCP
> always use the same port: 2049. But it is still odd. I wonder if it
> is needed at all.
It seems it broke for a more normal situation as well:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433881
Giving the "udp" option helped the user, though, but I don't really see why
the behavior changed.
/* Steinar */
--
Homepage: http://www.sesse.net/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sun, 2007-07-22 at 21:17 +0200, Steinar H. Gunderson wrote:
> On Mon, Jul 16, 2007 at 08:15:19PM +1000, Neil Brown wrote:
> > Hmmm.... That code looks a little odd. If you say you want udp, it
> > will still probe for tcp first. That doesn't hurt as UDP and TCP
> > always use the same port: 2049. But it is still odd. I wonder if it
> > is needed at all.
>
> It seems it broke for a more normal situation as well:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433881
>
> Giving the "udp" option helped the user, though, but I don't really see why
> the behavior changed.
>
> /* Steinar */
The default _had_ to change to TCP because UDP is just too unreliable
for NFS running with large (> 8k) r/w sizes, or on nonhomogeneous
networks (mixed 10/100/1000Gbit), or with fast clients.
Trond
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sun, Jul 22, 2007 at 05:58:13PM -0400, Trond Myklebust wrote:
> The default _had_ to change to TCP because UDP is just too unreliable
> for NFS running with large (> 8k) r/w sizes, or on nonhomogeneous
> networks (mixed 10/100/1000Gbit), or with fast clients.
Are you saying it changed between util-linux mount and nfs-utils mount.nfs? I
thought that change happened a lot earlier, and that this was something else.
/* Steinar */
--
Homepage: http://www.sesse.net/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-07-23 at 00:04 +0200, Steinar H. Gunderson wrote:
> On Sun, Jul 22, 2007 at 05:58:13PM -0400, Trond Myklebust wrote:
> > The default _had_ to change to TCP because UDP is just too unreliable
> > for NFS running with large (> 8k) r/w sizes, or on nonhomogeneous
> > networks (mixed 10/100/1000Gbit), or with fast clients.
>
> Are you saying it changed between util-linux mount and nfs-utils mount.nfs? I
> thought that change happened a lot earlier, and that this was something else.
The private versions of util-linux maintained by RedHat and SuSE (and
Debian?) transitioned earlier, but I don't believe we ever sent those
patches to the upstream maintainers of util-linux.
Trond
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs