You are not logged in.

#1 2009-08-16 11:58:14

Profjim
Member
From: NYC
Registered: 2008-03-24
Posts: 658

Out-of-date info re core/nfs-utils?

I'm just now getting up to speed on nfs/nfs4, so I could well be making mistakes here.

But my understanding is that the Arch nfs-utils package formerly didn't support nfs4, but as of June http://www.archlinux.org/news/452/, the package nfs4-utils from AUR was merged into the core/nfs-utils package. If that's right, then:

(1) shall I update the wiki entry on NFSv4 to point to the versions of librpcsecgss and nfs-utils in core, instead of aur/nfs4-utils and a (no-longer-existing) aur/librpcsecgss?

(2) is there still any point to having aur/nfs4-utils? It's confusing for those just getting nfs set up.

Third, I'm not sure that this comment from /etc/conf.d/nfs-common.conf is correct and up-to-date:

# Options to pass to rpc.statd.
# See rpc.statd(8) for more details.
# N.B. statd normally runs on both client and server, and run-time
# options should be specified accordingly. Specifically, the Arch
# NFS init scripts require the --no-notify flag on the server,
# but not on the client e.g.
# STATD_OPTS="--no-notify -p 32765 -o 32766" -> server
# STATD_OPTS="-p 32765 -o 32766" -> client

When I look at the /etc/rc.d/nfs-common script, I see that sm-notify is run after (and whenever) statd is, and that the script runs it explicitly, supplying the SMNOTIFY_OPTS specified in /etc/conf.d/nfs-common.conf. Is that the reason for adding --no-notify to STATD_OPTS? so that we have the chance to supply our SMNOTIFY_OPTS? Why are we instructed to say "--no-notify" on the server but not on the client? With the default /etc/conf.d/nfs-common.conf, NEED_STATD is blank, and so it will be set to "yes" in the /etc/rc.d/nfs-common script, and so statd and sm-notify will be run, on both the server and the client. I think I understand the instructions to set STATD_OPTS="...--no-notify..." on the server, but I'm still confused why we're supposed to omit them on the client. Is sm-notify not intended to run on the client? (but by default it does run). Is it meant to run on the client, but to ignore our SMNOTIFY_OPTS? (I think this is what is happening now.)

Fourth, the Arch patches to /usr/sbin/start-statd have that script source /etc/conf.d/nfs to obtain the user's STATD_OPTS. But they're now contained in /etc/conf,d/nfs-common.conf instead. I opened a bug report on this: FS#15950.

Offline

#2 2009-08-16 12:31:05

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,839

Re: Out-of-date info re core/nfs-utils?

1. Yes - more specifically, the NFS and NFSv4 wiki pages should be merged. The merge flag is already in place on the NFS page.
2. It should be deleted - request it on the aur-general mailing list.
3. I'd suggest you condense that into another bug report e.g. SMNOTIFY_OPS from conf.d/nfs-common.conf ignored, or something like that. That way, you can be sure a dev will look at it.

Offline

#3 2009-08-16 14:08:49

Profjim
Member
From: NYC
Registered: 2008-03-24
Posts: 658

Re: Out-of-date info re core/nfs-utils?

1. OK, for now edited just the NFSv4 wiki page to point to core/nfs-utils.
2. OK, posted request to aur-general.
3. OK, FS#15953

Last edited by Profjim (2009-08-16 14:15:38)

Offline

Board footer

Powered by FluxBB