Date: Thu, 2 Jun 2022 20:03:05 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John-Mark Gurney <jmg@funkthat.com> Cc: "freebsd-net@FreeBSD.org" <freebsd-net@FreeBSD.org> Subject: Re: make NFSv3 default now on diskless Message-ID: <YQBPR0101MB9742FCBB321B58DFC96CB3A3DDDE9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20220602183522.GZ88842@funkthat.com> References: <20220602032456.GY88842@funkthat.com> <YQBPR0101MB97426750C2E6717B06983AC7DDDE9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> <20220602183522.GZ88842@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney <jmg@funkthat.com> wrote:=0A=
> Rick Macklem wrote this message on Thu, Jun 02, 2022 at 14:44 +0000:=0A=
> > John-Mark Gurney <jmg@funkthat.com> wrote:=0A=
> > > I just booted FreeBSD-current diskless, using NFS root, and I ended=
=0A=
> > > up having issues because by default, NFS root is only v2.=0A=
> > >=0A=
> > > One of things that happened was disk space available was listed as=0A=
> > > -138G, or -144830429K. I assume this is because the server is report=
ing=0A=
> > > TBs instead.=0A=
> > Yes. NFSv2 uses 32bit sizes.=0A=
> =0A=
> Should we make the NFS server clamp various sizes then? instead of repor=
ting=0A=
> negative numbers? (Sorry if this is already done on newer versions of=0A=
> FreeBSD, my server is a bit old.)=0A=
My recollection (from long ago) is that, although the RFC defined them as 3=
2bit signed,=0A=
some implementations choose to mid-interpret them as unsigned, so that 4G w=
as supported=0A=
instead of 2G.=0A=
=0A=
Having said that, I agree with you that you should just use NFSv3 now. (Man=
y servers are=0A=
dropping NFSv2 support entirely.)=0A=
=0A=
> > > If I mount via mount_nfs, the sizes are normal/correct because it mou=
nts=0A=
> > > v3.=0A=
> > I believe most specify "nfsv3" in the "/" mount line of /etc/fstab on t=
he=0A=
> > remote root fs. Then, when the system does a "mount -u" to make it=0A=
> > read/write it gets toggled to NFSv3.=0A=
> =0A=
> well, I tried doing a:=0A=
> mount -u -o nfsv3 /=0A=
It used to work when it was in /etc/fstab, when going from read-only to rea=
d-write,=0A=
from what I recall.=0A=
=0A=
> on the system and this didn't work switch over to v3, it was still on=0A=
> v2..=0A=
>=0A=
> I haven't specified nfsv3 in /etc/fstab, but IMO, this should be the=0A=
> default..=0A=
Since NFSv3 is the default, it might not need to be explicit. I can't recal=
l.=0A=
=0A=
> =0A=
> Also, I'm right now booting single user mode, because I'm -mapall to=0A=
> a user, and lots of FreeBSD breaks when files aren't uid 0, and there=0A=
> doesn't appear to be a way to remap the uid to root (that I have found)..=
=0A=
Yep. It would take effect when going multi-user.=0A=
=0A=
"-mapall=3Droot", although that is not a recommended security setting.=0A=
Why don't you just allow the client to use whatever uid it would normally=
=0A=
use instead of "-mapall"?=0A=
=0A=
> > > The other issue that I ran into is that NFSv2 can't access >4GB files=
=0A=
> > > (or create them).=0A=
> > As above, NFSv2 uses 32bit sizes.=0A=
> >=0A=
> > > Anyone object to adding BOOTP_NFSV3 to GENERIC?=0A=
> > Well, that option only works when used with BOOTP_NFSROOT.=0A=
> > The GENERIC configs for amd64, arm64,... use the other way.=0A=
> > (Just to make it confusing, there are two different ways an NFS root=0A=
> > fs is set up.)=0A=
> > See below.=0A=
> >=0A=
> > > Or maybe making it a=0A=
> > > tunable that defaults to set, because it seems a bit crazy to default=
=0A=
> > > to v2 these days.=0A=
> > I don't think changing the default to NFSv3 will be a problem.=0A=
> > The reason it was NFSv2 was that,=0A=
> > for some non-FreeBSD NFS servers, the NFSv3 file handle is different=0A=
> > than the NFSv2 one.=0A=
> >=0A=
> > I added NFSv3 support to stand/libsa/nfs.c about 15years ago, so every=
=0A=
> > system should be running the newer NFS code in the loader and be able=
=0A=
> > to do NFSv3 booting.=0A=
> >=0A=
> > > This option was added in 432aad0e in 1997 so that the nfs_diskless=0A=
> > > structure didn't need to be filled out. Does anything even=0A=
> > > populate/fill it out anymore? I saw code in i386/i386/locore.s that=
=0A=
> > > does this, but it doesn't appear anywhere else.=0A=
> > Yes. For "options NFS_ROOT" (the other way), the loader uses=0A=
> > "stand/libsa/nfs.c" to acquire the remote file system's root file handl=
e=0A=
> > and fills it in. (See nfs_setup_diskless() in sys/nfs/nfs_diskless.c.)=
=0A=
> > Looking at it, it appears to enable NFSv3 so long as it finds=0A=
> > "boot.nfsroot.nfshandlelen" set.=0A=
>=0A=
> Well, I'm not seeing that, and this system is booting via=0A=
> pxeboot+loader, so maybe something is broken?=0A=
If it's an up to date (within last 10+ years then, yes, it sounds like it=
=0A=
might be broken. However, I'm not a loader guy...=0A=
=0A=
You can set it manually at the loader prompt to "28" and then see if it=0A=
boots are is running NFSv3.=0A=
=0A=
I have no way of testing/debugging this. Maybe you can figure out why the=
=0A=
loader isn't setting "boot.nfsroot.nfshandlelen" to 28?=0A=
=0A=
> > > There also appears to possibly be a way via mount options, but I can'=
t=0A=
> > > see where it's documented to set them.=0A=
> > I think you just specify "nfsv3" as a mount option in the root fs=0A=
> > line in /etc/fstab on the root fs on the NFS server.=0A=
>=0A=
> See above, this doesn't appear to work, or doesn't work the way I think=
=0A=
> it should...=0A=
Well, maybe I just don't recall correctly.=0A=
=0A=
>=0A=
> > I don't think changing the default to NFSv3 will be a problem.=0A=
> > The hassle is testing the various cases, to make sure nothing=0A=
> > breaks. I have no diskless setup to do testing and I don't even know=0A=
> > when installs/upgrades actually replace the loader?=0A=
>=0A=
> Well, this diskless was easier to setup than I expected, partly=0A=
> because I already had most of the infrastructure together (from=0A=
> netbooting another machine). Put pxeboot on a tftp server, configure=0A=
> the dhcp server to send the correct options, extract base.txz to a=0A=
> directory, export it, and it worked. I assume that I'm getting loader=0A=
> from that install since I don't specify it in the dhcp server.=0A=
I didn't think pxeboot used dhcp and I don't know how it figures out=0A=
where to find a file for booting?=0A=
=0A=
> As for testing, we have the CI system for that, right? ;p=0A=
>=0A=
> /me needs to get back to work on the lab.=0A=
>=0A=
> I guess we'd need to list the configurations that we care about, the=0A=
> only ones I can think of, off the top of my head are pxeboot (which I'm=
=0A=
> testing now), and u-boot..=0A=
> For servers, are there any servers that=0A=
> are NFSv2 only that are in common use today?=0A=
You'd have to look pretty hard. FreeBSD had NFSv3 from day 1,=0A=
since it was in the CSRG stuff.=0A=
> If you're running an=0A=
> ancient server that is NFSv2 only, I think you deserve to have to=0A=
> rebuild kernels or something instead of making 99% of the rest of us=0A=
> do it..=0A=
If you are running a NFSv2 only server, you are running a computer museum.=
=0A=
(As noted, many servers are dropping NFSv2 support entirely.)=0A=
=0A=
rick=0A=
=0A=
=0A=
--=0A=
John-Mark Gurney Voice: +1 415 225 5579=0A=
=0A=
"All that I will do, has been done, All that I have, has not."=0A=
=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB9742FCBB321B58DFC96CB3A3DDDE9>