Re: NFSv2 boot & OLD_NFSV2

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Sun, 26 Mar 2017 20:00:07 +0000
Just in case it wasn't clear, I think this is a good idea and I think
you have a handle on any potential problems.

Good luck with it, rick
________________________________________
From: Toomas Soome <tsoome_at_me.com>
Sent: Tuesday, March 21, 2017 5:04:59 AM
To: Daniel Braniss
Cc: Baptiste Daroussin; Rick Macklem; FreeBSD Current
Subject: Re: NFSv2 boot & OLD_NFSV2

On 21. märts 2017, at 10:50, Daniel Braniss <danny_at_cs.huji.ac.il<mailto:danny_at_cs.huji.ac.il>> wrote:


On 21 Mar 2017, at 10:13, Baptiste Daroussin <bapt_at_FreeBSD.org<mailto:bapt_at_FreeBSD.org>> wrote:

On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote:

On 20 Mar 2017, at 23:55, Toomas Soome <tsoome_at_me.com<mailto:tsoome_at_me.com>> wrote:


On 20. märts 2017, at 23:53, Rick Macklem <rmacklem_at_uoguelph.ca<mailto:rmacklem_at_uoguelph.ca>> wrote:

Baptiste Daroussin wrote:
On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
Hi!

The current boot code is building NFSv3, with preprocessor conditional OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?

rgds,
toomas

I vote burn

Bapt
I would be happy to see NFSv2 go away. However, depending on how people configure
their diskless root fs, they do end up using NFSv2 for their root fs.

Does booting over NFSv3 affect this?

I think the answer is no for a FreeBSD server (since the NFSv2 File Handle is the same as
the NFSv3 one, except padded with 0 bytes to 32bytes long).
However, there might be non-FreeBSD NFS servers where the NFSv2 file handle is different
than the NFSv3 one and for that case, the user would need NFSv2 boot code (or
reconfigure their root fs to use NFSv3).

To be honest, I suspect few realize that they are using NFSv2 for their root fs.
(They'd see it in a packet trace or via "nfsstat -m", but otherwise they probably
think they are using NFSv3 for their root fs.)

rick

if they do not suspect, they most likely use v3 - due to simple fact that you have to rebuild loader to use NFSv2 - it is compile time option.


old systems, 8.x, still use/boot v2, and so do old linux.
NetApp has discontinued support for v2, so we had to move this machines to use FreeBSD server and the day was
saved. So, till these machines get upgraded/discontinued we have a problem. There are several solutions
to this issue, but as long as it's a matter of getting rid for the sake of it, I would vote to keep it a while longer.

danny


Given you are speaking of 8.x I suppose you are using the loader that comes with
it, meaning you are safe if we remove it from the loader in 12.0 (note as said
by Toomas that is it is already off by default in the 12.0 loader) am I missing
something?


as usual, did not read the whole thread, I assumed - wrongly - that support for v2 would be discontinued.
removing v2 support from the boot process is fine! great, go for it. It will only involve newer
hosts, and simplifying the boot process is always a good idea.

sorry for the noise.
danny



yes, just to clarify,  the current loader code (in current), is having NFS code implemented as:

#ifdef OLD_NFSV2

v2 implementation is here

#else

v3 implementation is here

#endif

Which does mean that pxeboot/loader.efi is built by default to use v3 only, but we do have 2 parallel implementations of the NFS readers. And yes, the question is just about boot loader reader code (we do not implement NFS writes) - and we are *not* talking about server side there.

Indeed it also is possible to merge those 2 version implementations, but to be honest, I see very little point of doing that either, even if there is some setup still with v2 only server, there is still an option just to use TFTP based boot - especially given that current boot loader does provide parallel option to use either NFS or TFTP (via dhcp option 150), with existing binaries - that is, without having to re-compile.

rgds,
toomas
Received on Sun Mar 26 2017 - 18:00:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC