Received-SPF: pass (google.com: domain of linux-nfs+bounces-2734-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <8f363925-e72b-4484-9a94-aed044bb1967@redhat.com>
Date: Tue, 9 Apr 2024 13:20:18 -0400
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: nfs-utils' .service files not usable with nfsv4-server.service
To: Ian Kent <raven@themaw.net>, Chuck Lever III <chuck.lever@oracle.com>,
 Matt Turner <mattst88@gmail.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
References: <CAEdQ38GJgxponxNxkcv+t8mhwRPzOjan58MTBgOL8p9tY=rvTw@mail.gmail.com>
 <79c69668-4f8e-448e-9f50-6977cda662fc@redhat.com>
 <CAEdQ38FOP0_g0FK5DYz954OwfJjLUf2pjQL1CX=VNC60kd8HEw@mail.gmail.com>
 <50d1fcab-ba94-405e-896a-5bbae128998b@redhat.com>
 <3138D81C-EAD9-41CD-A32D-DEA4AA002CEE@oracle.com>
 <1a5a0fcd-0514-42ae-8d22-2d534327447f@themaw.net>
 <6dbecf8d-1074-48bb-8395-e4edf2c53109@redhat.com>
 <b881f549-6b50-4ab3-9df3-bebdaa326a70@themaw.net>
Content-Language: en-US
From: Steve Dickson <steved@redhat.com>
In-Reply-To: <b881f549-6b50-4ab3-9df3-bebdaa326a70@themaw.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 4/9/24 1:53 AM, Ian Kent wrote:
> On 8/4/24 19:01, Steve Dickson wrote:
>> Hey Ian!
>>
>> Good to hear from you!!
>>
>> On 4/7/24 7:57 PM, Ian Kent wrote:
>>> On 8/4/24 00:29, Chuck Lever III wrote:
>>>>> On Apr 7, 2024, at 10:45 AM, Steve Dickson <steved@redhat.com> wrote:
>>>>>
>>>>> On 4/6/24 6:26 PM, Matt Turner wrote:
>>>>>> On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <steved@redhat.com> 
>>>>>> wrote:
>>>>>>> Unfortunately the idea of having a nfsv4 only server
>>>>>>> did not go over well with upstream.
>>>>>> Which upstream do you mean? nfs-utils, Linux kernel?
>>>>> The NFS server maintainers... they didn't push back hard
>>>>> but the didn't it was necessary.
>>>> I'm sympathetic to some folks wanting a narrower footprint,
>>>> but I think we'd like to have support for all versions
>>>> packaged and available for an NFS server administrator,
>>>> right out of the shrink-wrap. Currently, most installations
>>>> want to deploy v3 and v4, so we should cater to the common
>>>> case.
>>>
>>> I have to say I agree with Chuck.
>> Yes... I definitely see Chuck's point.
>>
>>>
>>>
>>> Over the years I have had to deal with the consequences of dropping 
>>> support
>>>
>>> for NFS versions. So far that has been at the distribution level but 
>>> if it
>>>
>>> had been at the upstream level I would have had a much harder time of 
>>> it.
>>>
>>>
>>> am-utils for example, yes it's maybe not a good case because it lacks 
>>> upstream
>>>
>>> support nowadays, but I still work on it. It uses an NFS client 
>>> implementation
>>>
>>> to provide automount support and NFS v2 was ideal for the localhost 
>>> server but
>>>
>>> v2 support was removed from distro kernel builds and I had to 
>>> implement an NFS
>>>
>>> v3 server for this which was very much overkill.
>> My apologies... That was me. Removing v2 cut down
>> the testing matrix two-fold. v3 was there to replace
>> v2... I just did the obvious.
> 
> Hehe, Yeah, I know.
> 
> 
> But this seemed like a good opportunity to let you know these changes 
> can be rather
> 
> inconvienient for some so that you have all the information when making 
> changes at
> 
> a later time.
Point taken....

> 
> 
> Even removing UDP support from the Fedora kernel config caused a problem 
> for me.
> 
> 
> Again, am-utils, it had a bug with it's background processing that was 
> causing slow mounts
> 
> that, ASAICS, could only be fixed by using UDP (which is sensible for a 
> service running or
> 
> localhost) or re-writting the entire application to use threads, a good 
> idea but way too much
> 
> work.
> 
> 
> OTOH we always knew the amd application would die in time to come so it 
> isn't such a big
> 
> deal I suppose.
Again it was a testing matrix thing... Plus TCP handled network
congestion much better than NFS ever could

> 
> 
>>
>>>
>>>
>>> Now there's talk of dropping v3 support which will spell the end of 
>>> am-utils,
>>>
>>> unnecessarily IMHO.
>> Yes... I was poking the bear when I said "deprecate" v3. Knowing
>> full well it would go over like a lead balloon :-)
>>
>> But coming up with a way of separating the protocols
>> so only one can be used (client or server) in VMs or
>> containers is a bad idea?
> 
> Yes, that's a bit harder and I think will require a division of the 
> packages ...
Right...

steved.
> 
> 
>>
>>>
>>>
>>> I can understand the urge to drop v2 but there are still many v3 
>>> users so I wonder
>>>
>>> about the wisdom of even thinking about dropping v3 support and 
>>> multiple packages,
>>>
>>> IMHO, will introduce an unnecessary downstream overhead. It's hard 
>>> enough to keep
>>>
>>> up with the workload as it is.
>>>
>>>
>>> I also gat that mostly what I'm saying has happened at distro level 
>>> but please don't
>>>
>>> go down this path upstream too.
>> You are right... this is distro level conversation but
>> upstream should be involved... IMHO.
> 
> Indeed, yes.
> 
> 
> Ian
> 
>>
>> steved.
>>
>>>
>>>
>>> Ian
>>>
>>>>
>>>> As I recall, the NFSv4-only mechanism proposed at the time
>>>> was pretty clunky. If you have alternative ideas, I'm happy
>>>> to consider them. But let's recognize that an NFSv4-only
>>>> deployment is the special case here, and not make life more
>>>> difficult for everyone else, especially folks who might
>>>> start with an NFSv4-only deployment and need to add NFSv3
>>>> later, for whatever crazy reason.
>>>>
>>>> The nfs-server unit should be made to do the right thing
>>>> no matter what is installed on the system and no matter what
>>>> is in /etc/nfs.conf. I don't see why screwing with the
>>>> distro packaging is needed?
>>>>
>>>> -- 
>>>> Chuck Lever
>>>>
>>>>
>>>
>>
>