Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Mar 2013 13:40:39 +0100
From:      Andre Oppermann <andre@freebsd.org>
To:        Peter Wemm <peter@wemm.org>
Cc:        rmacklem@uoguelph.ca, freebsd-current@freebsd.org, bright@mu.org
Subject:   Re: NewNFS vs. oldNFS for 10.0?
Message-ID:  <51470B47.7040108@freebsd.org>
In-Reply-To: <CAGE5yCoKUijTDJk6uh9ROch-CAdkTAVJt3cvf0oKRmKhJT9Niw@mail.gmail.com>
References:  <514324E8.30209@freebsd.org> <201303150946.29100.jhb@freebsd.org> <51433D30.30405@freebsd.org> <201303151703.09688.jhb@freebsd.org> <CAGE5yCoKUijTDJk6uh9ROch-CAdkTAVJt3cvf0oKRmKhJT9Niw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 16.03.2013 01:44, Peter Wemm wrote:
> On Fri, Mar 15, 2013 at 2:03 PM, John Baldwin <jhb@freebsd.org> 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.
>
> Yes to both.  As somebody who uses oldNFS in production in 9.x, I can
> vouch for that.

Sounds like we have a plan.

> Personally I'd like to see oldnfs go away from head after a
> comfortable dust-settling period 8.4-R and then call it a day.

Since 8.4-R is scheduled for this year(-ish), actually for mid-April,
that would put OldNFS going away around mid to later summer 2013.

Current users of OldNFS on 10-CURRENT should start to test NewNFS and
report any issues they find.  The maintainer of NewNFS is very responsive
and tries hard to fix problems given a sufficient precise problem report.

Users of OldNFS on 9-STABLE should also start to test NewNFS and report
any issues, especially divergent behavior to OldNFS.

> Although, please, as part of this please hunt down and s/newnfs/nfs/g
> in the process.  This should be done well before 10.x so loose ends
> can be tracked down and fixed.

Later summer 2013 fits very well with this and gives about 4 month's of
leading time for a theoretical start of the 10.0 release process.

This seems to be the majority consensus unless someone forcefully objects
on technical grounds and is willing to provide quality input to help
fixing NewNFS regressions.

-- 
Andre




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51470B47.7040108>