Re: Diskless setup with NFS_V4

On Fri, Aug 23, 2013 at 09:32:35AM -0400, Rick Macklem wrote:

> Slawa Olhovchenkov wrote:
> > Its posible use currentle FreeBSD on NFS_V4 root?
> > 
> > Explain:
> > 
> > pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel.
> > In this setup kernel can use only configured (established) nfs fh.
> > This is not allowed to switch version or some options.
> > 
> > When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP
> > discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options)
> > 'nfsv4' option.
> > 
> > nfs/nfs_diskless.c:nfs_setup_diskless also initialy set
> > 
> > nd3->root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE |
> > NFSMNT_RESVPORT);
> > 
> > and don't allow 'nfsv4' option.
> > 
> > Where I be wrong?
> > How I can use diskless setup with R/O root on NFS_V4 share?
> No. There are a couple of problems that would need to be resolved
> for an NFSv4 root fs to work.
> 1 - An NFSv4 mount needs a unique identifier for the client machine.
>     It currently uses the host uuid, but that is filled in by a
>     userland utility run from the root fs (ie. not available soon enough).
>     Linux uses the ip host address for this, which I believe is bogus
>     and inappropriate.

As I see in /etc/rc.d/hostid first try is 'kenv -q
smbios.system.uuid'. This is not need userland utility.

> 2 - Without the nfsuserd daemon running, there is currently no uid/gid<-->name
>     mappings available. This might work, but there would be a lot of "file owned
>     by nobody" situations that could cause problems.

This is ok for kernel loading and is same as NFSv3.

>     I suspect this can be fixed by hardwiring a few mappings (root, bin,...),
>     but there is currently no code to do this.
>     The Linux solution for this is to put the number in a string on the wire
>     and the updated draft of RFC3530 (called rfc3530bis, not yet an RFC) allows
>     this, so eventually this will be supported by most/all servers.
> 
> Until 1 and 2 are resolved, doing an NFSv4 root fs mount is not practical.
> To be honest, I don't see a need for it, since I'm "old fashioned" and still
> believe that the root fs should be a small volume of critical system utilities
> only, so an NFSv3 mount of it should be sufficient. (ie. If /var and any
> other subtrees where files might get byte range locked are on separate volumes,
> I think it should be fine with a NFSv3 root fs mount, even without running rpc.lockd.)

I am try to build many diskless workers with fat software.
NFSv4 targeting as more fast. And NFSv4 don't have problem with
different UIDs.