From owner-freebsd-current@FreeBSD.ORG Sat Mar 16 00:43:09 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 50D3032F; Sat, 16 Mar 2013 00:43:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id DBF6881F; Sat, 16 Mar 2013 00:43:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKW9Q1GDaFvO/2dsb2JhbABDiDG6FYJlgX10gioBAQQBI1YFFg4KAgINGQJZBoghBrEJkl2BI4EqjBQ0B4ItgRMDlluRAoMmIIFs X-IronPort-AV: E=Sophos;i="4.84,854,1355115600"; d="scan'208";a="19264370" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 15 Mar 2013 20:43:07 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 603ADB3EE1; Fri, 15 Mar 2013 20:43:07 -0400 (EDT) Date: Fri, 15 Mar 2013 20:43:07 -0400 (EDT) From: Rick Macklem To: John Baldwin Message-ID: <1627787090.3962321.1363394587341.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201303151703.09688.jhb@freebsd.org> Subject: Re: NewNFS vs. oldNFS for 10.0? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, Andre Oppermann 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: Sat, 16 Mar 2013 00:43:09 -0000 John Baldwin wrote: > On Friday, March 15, 2013 11:24:32 am Andre Oppermann wrote: > > 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? > > I thought I implied one above: when 8.x is EOL'd. However, that has > more to do > with developer convience. It's actually a PITA to use the old NFS > client even > on 9.0. > > > 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? > > No. The old client doesn't work out of the box unless you change your > fstab > to s/nfs/oldnfs/. Also, tools like nfsstat don't work with the old nfs > client > either. > Just fyi, "nfsstat -o" should still report stats for the old NFS. (I suspect John meant that it does not by default.) > Do you have an actual reason for wanting this change? As someone who > is actively > working on NFS (and applying and testing fixes on both old and new) > I'd like to > keep the old one for now. Does that break something for you? > > -- > John Baldwin