From owner-freebsd-current@FreeBSD.ORG Fri Mar 15 15:24:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42A24250 for ; Fri, 15 Mar 2013 15:24:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 93FF2890 for ; Fri, 15 Mar 2013 15:24:36 +0000 (UTC) Received: (qmail 70835 invoked from network); 15 Mar 2013 16:36:36 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Mar 2013 16:36:36 -0000 Message-ID: <51433D30.30405@freebsd.org> Date: Fri, 15 Mar 2013 16:24:32 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: NewNFS vs. oldNFS for 10.0? References: <514324E8.30209@freebsd.org> <201303150946.29100.jhb@freebsd.org> In-Reply-To: <201303150946.29100.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, rmacklem@uoguelph.ca X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Fri, 15 Mar 2013 15:24:37 -0000 On 15.03.2013 14:46, John Baldwin wrote: > On Friday, March 15, 2013 9:40:56 am Andre Oppermann wrote: >> Hi Rick, all, >> >> is there a plan to decide for one NFS implementation for FreeBSD 10.0, >> or to keep both around indefinately? >> >> I'm talking about: >> oldNFS in sys/{nfs, nfsclient, nfsserver} NFSv2+NFSv3 >> newNFS in sys/fs/{nfs, nfsclient, nfsserver} NFSv2+NFSv3+NFSv4 >> >> NewNFS supports newer NFS standards and seems to have proven itself in >> some quite heavy traffic environments. >> >> Is there any reason to keep oldNFS around other than nostalgic? > > It can probably be removed. It's kind of handy to keep around as long as 8.x > is around since it uses oldNFS by default as it makes merging bugfixes to the > NFS client a bit easier (you fix both clients in HEAD and can then just svn > merge both of those to 8 and 9). Having several fixes to the NFS client > recently and being in a position of still using 8.x with oldNFS in production, > I would prefer to not remove it quite yet. Do you have a timeframe on the sunset of oldNFS in HEAD so we can communicate a) that oldNFS won't be in 10.0; and b) it will go on date X? Would it make sense to make oldNFS more difficult to compile into the kernel on HEAD to notify all those with legacy kernel config files? -- Andre