On Mon, 2013-07-08 at 10:47 -0400, Chuck Lever wrote: > On Jul 5, 2013, at 3:52 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > On Fri, Jul 05, 2013 at 10:59:59AM -0400, Chuck Lever wrote: > >> > >> It feels like we should have a plan for both the server and client. > > > > That discussion brought out of the woodwork a couple people still > > claiming to depend on v2. They seemed to only care about the server > > side (because they had some old (non-linux) clients that were still > > using v2 for some reason). > > > > There could be other cases of people depending on an application tied to > > an obsolete client OS that still expect to be able to upgrade their > > server. > > > > I may be wrong, but I'd expect the same situation (needing an obsolete > > server to be able to access some data) to be rarer. (One possible > > exception I noticed is vesta: http://www.vestasys.org/--source-code > > management system with built-in v2-only server. Wonder if it's still > > alive??) > > > > Anyway I'm inclined to treat dropping server protocol support by the > > same standard as we'd treat dropping kernel ABI: as in, it's only OK if > > we don't expect anyone to notice. > > I'm wondering why this requirement does not also apply to the client. I've heard the opinion expressed recently that we really should not deprecate a feature that still has users. > > It might be reasonable to bring this question up on lkml, specifically in the context of NFS version 2. > > For the sake of argument, what would induce us to keep NFSv2 in the client? Finding someone to maintain it? > Finding users... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
