home | list info | list archive | date index | thread index

Re: [SIGS-L3GO] Reminder of L3GO meeting this evening.

> On 12/04/16 09:17 AM, Alex Pilon wrote:
> > Anybody need a 4 gig SO-DIMM stick that I pulled from a Thinkpad
> > T460?
>
On Tue, Apr 12, 2016 at 01:23:17PM -0400, Ian Stakenvicius wrote:
> YES, i could definitely use the ram!

Sold to the man in… !

> Unfortunately I won't be there as my kid's fallen ill today.  Can
> you hold onto it until next month or maybe we can make arrangements
> to meet in the interim?

Contact me out of band for that. Else next L3GO/OCLUG.

> On 12/04/16 09:17 AM, Alex Pilon wrote:
> > Got pure NFSv4 working. Will respond to OCLUG later.
>
On Tue, Apr 12, 2016 at 01:23:17PM -0400, Ian Stakenvicius wrote:
> Great to hear about pure NFSv4 too -- how much patching did that entai
> l?

No patching, nor figuring out how to build kernel. I was just trying to
figure out which daemons to run and configure. I already figured the
rest. I meant no v4 at runtime.

Really was just that just because the mount protocol is integrated into
NFSv4, not a sideband channel doesn't mean that you don't need
`rpc.mountd -N 2 -N 3` to be running so that the initial NFS mount
request works.

The documentation (nfs(5), various wikis and mailing lists) were just
confusing because they said that the mount protocol was rolled into the
core protocol, without being explicit on whether you need the mount
helper/daemon. I think there was one that explicitly said that you don't
need mountd, and another one that clearly implicitly said the same.

So in short, you need:

- rpc_pipefs mounted on server
- rpc.nfsd -N 2 -N 3 $NUMBER_OF_NFSD_THREADS
- rpc.mountd -N 2 -N 3
- nfsidmap for the client, not a daemon, but one-shot upcall program
- rpc.idmapd/nfsidmap, forget which for server, but rpc.idmapd was
  running in my case

It was stupidly simple.

You don't need:

- rpc.statd
- rpcbind
- portmapper

I'm not doing these advanced things… at least not yet for GSS:

- blkmapd
- nfsdcltrack
- rpc.gssd

You can't build the NFSv4 server support into the kernel without it
depending on the NFSv3 server support, even if neutered. All that is
obvious when you `make nconfig` (please don't menuconfig, or any of the
other ones).

However, you can build the NFSv4 client without NFSv3 client support.

I didn't bothering looking into how to build nfs-utils without NFSv3 in
detail. Doesn't seem possible without patching, at least not with just
the configure script. Would be nice to totally clean it out.

If you really want lightweight, you should go busybox, but it doesn't
allow to remove NFSv3 support, and I don't know the state of its support
for advanced NFSv4 features, if they are at all in userspace, or
negotiated.