[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: any fundamental difference between fedora and suse NFSv4?



On Sun, 3 Jan 2010, Ed Greshko wrote:

> Robert P. J. Day wrote:
> >   i'm currently reviewing a doc on suse linux enterprise 11, the
> > section on NFS, but i don't have a SLES 11 machine in front of me.
> > could anyone who uses both SLES 11 and fedora 12 comment on how
> > indistinguishable the NFS setups are across those two distros?
> >
> >   so far, i haven't seen a lot that's massively incompatible, and
> > i wouldn't expect to.  obviously, the fundamental files are going
> > to be the same.

... snip ...

> Should I get the chance to experiment with NFSv4 on it I will.
> Probably try to export and mount file systems from/to a F12 system.
> Sounds like a nice challenge.

  ok, a few questions/observations regarding nfsv4, if i might.  as i
mentioned in an earlier post, i'm working off of this:

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Deployment_Guide/ch-nfs.html

and seeing what it would take to set up a simple NFS configuration on
fedora 12 that uses *nothing* but nfsv4.  so feel free to comment on
the following suppositions:

* NFSv4 appears to be a stable technology that should work.  (there is
an NFS 4.1 that is labelled as experimental, but am i correct in
assuming that NFSv4 is supposed to work properly?)

* i did notice that mounting via NFSv4 requires the "-t nfs4" mount
option, not just "-t nfs".  is that actually a *requirement*?  is the
mount command not smart enough to figure that out?

* as i read it, nfsv4 no longer requires portmapper, rpc.mountd,
rpc.lockd or rpc.statd, which inspires the question -- if you're
running *exclusively* NFSv4, is there any reason to even *start* those
last three daemons?

  i ask since i'm looking at the startup script /etc/init.d/nfs, and
the "start" argument is processed thusly:

# See how we were called.
case "$1" in
  start)

        # Check that networking is up.
        [ "${NETWORKING}" != "yes" ] && exit 6

        [ -x /usr/sbin/rpc.nfsd ] || exit 5
        [ -x /usr/sbin/rpc.mountd ] || exit 5
        [ -x /usr/sbin/exportfs ] || exit 5
	... snip ...

  the problem, of course, is that if you're running exclusively NFSv4,
what's the point of checking for the existence of /usr/sbin/rpc.mountd
if you have no need to run it?   and that same startup sequence
invokes rpc.mountd later, again unnecessarily.


 and as i mentioned in an earlier
posting, if i make this change to /etc/sysconfig/nfs:

MOUNTD_NFS_V1="no"
MOUNTD_NFS_V2="no"
MOUNTD_NFS_V3="no"

then when i run "service nfs restart", i get:

# service nfs restart
Shutting down NFS mountd:                                  [  OK  ]
Shutting down NFS daemon:                                  [  OK  ]
Shutting down NFS quotas:                                  [  OK  ]
Shutting down NFS services:                                [  OK  ]
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd: Usage: rpc.mountd [-F|--foreground] [-h|--help]
[-v|--version] [-d kind|--debug kind]
	[-o num|--descriptors num] [-f exports-file|--exports-file=file]
	[-p|--port port] [-V version|--nfs-version version]
	[-N version|--no-nfs-version version] [-n|--no-tcp]
	[-H ha-callout-prog] [-s|--state-directory-path path]
	[-g|--manage-gids] [-t num|--num-threads=num]
                                                           [FAILED]
#

  debugging the call to start rpc.mountd shows it being invoked with
the following args:

--no-nfs-version 1 --no-nfs-version 2 --no-nfs-version 3

which i would have *thought* is what i wanted to see.  apparently not.

  in conclusion, what capability *should* i expect from NFSv4 on
fedora 12?  can't i even *start* it without supporting earlier
versions?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]