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@xxxxxxxxxx> wrote:
On 4/6/24 6:26 PM, Matt Turner wrote:
On Sat, Apr 6, 2024 at 4:37 PM Steve Dickson <steved@xxxxxxxxxx>
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.
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.
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 ...
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
