All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.