From owner-freebsd-current@freebsd.org Sun Mar 26 20:00:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98ACCD1E67D for ; Sun, 26 Mar 2017 20:00:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660040.outbound.protection.outlook.com [40.107.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87E8F15D7; Sun, 26 Mar 2017 20:00:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Sun, 26 Mar 2017 20:00:08 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0991.020; Sun, 26 Mar 2017 20:00:08 +0000 From: Rick Macklem To: Toomas Soome , Daniel Braniss CC: Baptiste Daroussin , FreeBSD Current Subject: Re: NFSv2 boot & OLD_NFSV2 Thread-Topic: NFSv2 boot & OLD_NFSV2 Thread-Index: AQHSoabzN3fGlEoBW0OV/vmFdatswaGeGqEAgAAonNqAAALjgIAAqGOAgAAERoCAAApggIAAA/eAgAiSfbo= Date: Sun, 26 Mar 2017 20:00:07 +0000 Message-ID: References: <38DD1950-AD12-4A27-8335-54F997E408DF@me.com> <20170320192000.6hal22ibnr3ajog3@ivaldir.net> <1B7471CD-2F2D-4F22-9D25-E46580CF9E96@me.com> <84D239AB-AB57-4A50-9700-E42BBF9CBE5A@cs.huji.ac.il> <20170321081339.2wbx3rb32qdavvn3@ivaldir.net> <80C5425F-9A71-45D9-BA41-229E4E72EC36@cs.huji.ac.il>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: me.com; dkim=none (message not signed) header.d=none;me.com; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:xhOirgO+4/FsXrVxThjHPJMev2MO5ZXLAEsuOVqIR8b8AlxzKTexZ/UHDm/T3MO1+qP862w/Xse3BZfJ1x/Hk6oLvjGWYpVkL2OG54zggK7mXo24vJjjiDRtSz3MfR1jYFVXkqOvDmNbw0QGvCNaP3QEgTBWFRIaEN30JW0QAFpyVWJjr2bmBdjwL+1fgroBt7X/PW70OU5b5AEMX3QK0fDsiKCHm5qRM+lN0puHPZokAmopXMsNy3X6if7zsHEqMl0297TL0PcoZKyEDOPjmqpyNc2x+ZL7cAdLxPLbX8hoKQkznM4zu/YvvTEGAVAJVZyITprPvfk8ebxWWMSOmQ== x-ms-office365-filtering-correlation-id: ffb40c79-dac6-4575-b4f3-08d47482b401 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(188474585043545); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39830400002)(39410400002)(24454002)(377454003)(2906002)(55016002)(54906002)(9686003)(3660700001)(3280700002)(6436002)(8656002)(33656002)(53936002)(25786009)(38730400002)(229853002)(39060400002)(6246003)(2900100001)(189998001)(74482002)(102836003)(54356999)(5660300001)(81166006)(50986999)(86362001)(76176999)(7696004)(8676002)(93886004)(2950100002)(305945005)(74316002)(6506006)(77096006)(53546009)(4326008)(122556002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 20:00:07.9101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 20:00:11 -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 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=E4rts 2017, at 10:50, Daniel Braniss > wrote: On 21 Mar 2017, at 10:13, Baptiste Daroussin > wrote: On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote: On 20 Mar 2017, at 23:55, Toomas Soome = > wrote: On 20. m=E4rts 2017, at 23:53, Rick Macklem > 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 con= figure 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 roo= t fs. (They'd see it in a packet trace or via "nfsstat -m", but otherwise they pr= obably 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 y= ou 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 s= aid by Toomas that is it is already off by default in the 12.0 loader) am I mis= sing 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 wil= l 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 wr= ites) - 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 pa= rallel option to use either NFS or TFTP (via dhcp option 150), with existin= g binaries - that is, without having to re-compile. rgds, toomas