Date: Sat, 24 Aug 2013 00:56:41 +0400 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: current@freebsd.org Subject: Re: Diskless setup with NFS_V4 Message-ID: <20130823205641.GY3796@zxy.spb.ru> In-Reply-To: <1503899038.12819687.1377264755464.JavaMail.root@uoguelph.ca> References: <20130822133520.GA75880@zxy.spb.ru> <1503899038.12819687.1377264755464.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130823205641.GY3796>