From: "J.A. Magallón" <jamagallon@ono.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>, linux-nfs@vger.kernel.org
Subject: Re: Questions and problems with NFS4
Date: Fri, 30 Jul 2010 02:18:37 +0200 [thread overview]
Message-ID: <20100730021837.65549fa7@werewolf.home> (raw)
In-Reply-To: <4C507208.6030309@oracle.com>
On Wed, 28 Jul 2010 14:08:08 -0400, Chuck Lever <chuck.lever@oracle.com> wrote:
> On 07/27/10 06:46 PM, J.A. Magallón wrote:
> > - AFAIK, with NFS4 the only needed daemons are nfsd and idmapd. And the
> > only accesible port from the outside is 2049, for nfsd.
> > I have tried to strip down my nfs server (-N 2 -N 3 -U),
> > but rpcinfo still gives me:
> >
> > annwn:~# rpcinfo -p localhost
> > program vers proto port service
> > 100000 4 tcp 111 portmapper
> > 100000 3 tcp 111 portmapper
> > 100000 2 tcp 111 portmapper
> > 100000 4 udp 111 portmapper
> > 100000 3 udp 111 portmapper
> > 100000 2 udp 111 portmapper
> > 100024 1 udp 48461 status
> > 100024 1 tcp 37515 status
> > 100021 1 udp 38583 nlockmgr
> > 100021 3 udp 38583 nlockmgr
> > 100021 4 udp 38583 nlockmgr
> > 100021 1 tcp 37873 nlockmgr
> > 100021 3 tcp 37873 nlockmgr
> > 100021 4 tcp 37873 nlockmgr
> > 100003 4 tcp 2049 nfs
> > 100005 1 udp 45341 mountd
> > 100005 1 tcp 58639 mountd
> >
> > disabling portampper and mountd is just a matter of initscripts
> > requirements, but how can I disable nlockmgr ? It isn't needed for
> > NFS4, isn't it ? Nor portmapper nor mountd...
>
> Strictly speaking, portmapper is not required for NFSv4 service.
> However, the NFS infrastructure on Linux is still designed for NFSv2 and
> v3. There remains some work needed to make portmapper optional for a
> v4-only server. For now, continue to run it in order to handle kernel
> upcalls.
>
> rpc.mountd is, however, still required on Linux NFSv4 servers. Although
> NFSv4 clients do not contact the server's mountd, the kernel's NFS
> server performs upcalls to rpc.mountd to manage export information. You
> can firewall off the mountd service on the server without affecting
> NFSv4 clients. Recent versions of rpc.mountd accept command line
> options that disable the mountd network service while still handling
> kernel upcalls.
>
> And, as long as lockd is running, you will need to keep rpc.statd
> around. Again, you can firewall this service so that it is not exposed
> on the network, but it must continue to be available to handle kernel
> upcalls. This is something we hope to address eventually as part of the
> lockd work Bruce mentioned.
Err...
First of all, plz correct me if this is in some kind of wiki, web page or
the like, but I have not been able to find it. All this things should be
on a document somewhere, perhaps even in the kernel itself...
These are the things I have found out (thanks to your answers...).
I'm a long time unix admin, not new to NFS, but all this things were not
obvious to me, so perhaps they deserve to be in a document, something like
"NFS 3 to 4 migration for dummy admins":
- Everything just works if you mount shares as nfs4. Even, if you have a
bunch of linux boxen with recent kernel/nfs-utils, probably you are
already doing nfs4... modern mount tries nfs4 first.
- Using nfsroot with fsid=0 is not mandatory, nor bind-mounting everything
under some /export (like many documents say), that only forces you to
use the old way of specifying paths in the server (absolute, not
relative to /export).
- Even if you use nfsroot(fsid=0), and you mount it on the client
at /somepoint, you are not forced to mount everything else under
/somepoint (plz, correct me if I'm wrong).
- You can strip your server for NFS4, but not too much... Old daemons
are still needed locally. For example, you can get rid of NFS2 and
UDP for nfsd (-N 2 -U, -any os still uses NFS2??-), and old
mount protocols (-N 1 -N 2 for mountd)...
- ... but they can be firewalled, use is just local
- portmap/rpcbind is not needed, but still used because nfsd is not
yet proper clean for only-nfs4-behavior.
There are also some things I have not been able to discover, like
using the interesting things of NFS4:
- How do you activate delegations ? Is this an automatic thing, or
do I have to add any option somewhere ?
- How do you use cache ? Many docs talk about fsc option, but man
does not mention it (nfs-utils 1.2.2).
I have tried to use cachefiles module, and cachefilesd, but
when I try to run it, I get:
bran:~/c/cachefilesd-0.10# ./cachefilesd -dddns -f $PWD/cachefilesd.conf
About to bind cache
CacheFiles bind failed: errno 95 (Operation not supported)
In dmesg:
[cachef] ==> cachefiles_get_security_ID({system_u:system_r:cachefiles_kernel_t:s0})
CacheFiles: Security denies permission to nominate security context: error -95
I can not run cachefiles without SELinux or something like that ?
Thanks, perhaps this notes help someone in the future.
TIA
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
next prev parent reply other threads:[~2010-07-30 0:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 22:46 Questions and problems with NFS4 J.A. Magallón
2010-07-28 2:28 ` Bian Naimeng
2010-07-28 17:14 ` J. Bruce Fields
2010-07-28 18:08 ` Chuck Lever
2010-07-30 0:18 ` J.A. Magallón [this message]
2010-07-30 18:47 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100730021837.65549fa7@werewolf.home \
--to=jamagallon@ono.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.