On Wed, Mar 03, 2021 at 05:07:56PM -0500, Steve Dickson wrote:
>
>
> On 3/3/21 4:54 PM, J. Bruce Fields wrote:
> > On Wed, Mar 03, 2021 at 04:22:28PM -0500, Steve Dickson wrote:
> >> Hey!
> >>
> >> On 3/3/21 10:23 AM, J. Bruce Fields wrote:
> >>> On Tue, Mar 02, 2021 at 05:33:23PM -0500, Steve Dickson wrote:
> >>>>
> >>>>
> >>>> On 2/24/21 3:30 PM, J. Bruce Fields wrote:
> >>>>> On Fri, Feb 19, 2021 at 03:08:08PM -0500, Steve Dickson wrote:
> >>>>>> nfsv4.exportd is a daemon that will listen for only v4 mount upcalls.
> >>>>>> The idea is to allow distros to build a v4 only package
> >>>>>> which will have a much smaller footprint than the
> >>>>>> entire nfs-utils package.
> >>>>>>
> >>>>>> exportd uses no RPC code, which means none of the
> >>>>>> code or arguments that deal with v3 was ported,
> >>>>>> this again, makes the footprint much smaller.
> >>>>>
> >>>>> How much smaller?
> >>>> Will a bit smaller... but a number of daemons like nfsd[cld,clddb,cldnts]
> >>>> need to also come a long.
> >>>
> >>> Could we get some numbers?
> >>>
> >>> Looks like nfs-utils in F33 is about 1.2M:
> >>>
> >>> $ rpm -qi nfs-utils|grep ^Size
> >>> Size : 1243512
> >>>
> >>> $ strip utils/mountd/mountd
> >>> $ ls -lh utils/mountd/mountd
> >>> -rwxrwxr-x. 1 bfields bfields 128K Mar 3 10:12 utils/mountd/mountd
> >>> $ strip utils/exportd/exportd
> >>> $ ls -lh utils/exportd/exportd
> >>> -rwxrwxr-x. 1 bfields bfields 106K Mar 3 10:12 utils/exportd/exportd
> >>>
> >>> So replacing mountd by exportd saves us about 20K out of 1.2M. Is it
> >>> worth it?
> >> In smaller foot print I guess I meant no v3 daemons, esp rpcbind.
> >
> > The rpcbind rpm is 120K installed, so if the new v4-only rpm has no
> > dependency on rpcbind then we save 120K.
> I believe it is more of a functionally thing than a size thing
> WRT to containers.
OK. But if it's not about size, then we can use "rpc.mountd -N2 -N3",
we don't need a separate daemon.
--b.
On 3/3/21 5:17 PM, J. Bruce Fields wrote:
> On Wed, Mar 03, 2021 at 05:07:56PM -0500, Steve Dickson wrote:
>>
>>
>> On 3/3/21 4:54 PM, J. Bruce Fields wrote:
>>> On Wed, Mar 03, 2021 at 04:22:28PM -0500, Steve Dickson wrote:
>>>> Hey!
>>>>
>>>> On 3/3/21 10:23 AM, J. Bruce Fields wrote:
>>>>> On Tue, Mar 02, 2021 at 05:33:23PM -0500, Steve Dickson wrote:
>>>>>>
>>>>>>
>>>>>> On 2/24/21 3:30 PM, J. Bruce Fields wrote:
>>>>>>> On Fri, Feb 19, 2021 at 03:08:08PM -0500, Steve Dickson wrote:
>>>>>>>> nfsv4.exportd is a daemon that will listen for only v4 mount upcalls.
>>>>>>>> The idea is to allow distros to build a v4 only package
>>>>>>>> which will have a much smaller footprint than the
>>>>>>>> entire nfs-utils package.
>>>>>>>>
>>>>>>>> exportd uses no RPC code, which means none of the
>>>>>>>> code or arguments that deal with v3 was ported,
>>>>>>>> this again, makes the footprint much smaller.
>>>>>>>
>>>>>>> How much smaller?
>>>>>> Will a bit smaller... but a number of daemons like nfsd[cld,clddb,cldnts]
>>>>>> need to also come a long.
>>>>>
>>>>> Could we get some numbers?
>>>>>
>>>>> Looks like nfs-utils in F33 is about 1.2M:
>>>>>
>>>>> $ rpm -qi nfs-utils|grep ^Size
>>>>> Size : 1243512
>>>>>
>>>>> $ strip utils/mountd/mountd
>>>>> $ ls -lh utils/mountd/mountd
>>>>> -rwxrwxr-x. 1 bfields bfields 128K Mar 3 10:12 utils/mountd/mountd
>>>>> $ strip utils/exportd/exportd
>>>>> $ ls -lh utils/exportd/exportd
>>>>> -rwxrwxr-x. 1 bfields bfields 106K Mar 3 10:12 utils/exportd/exportd
>>>>>
>>>>> So replacing mountd by exportd saves us about 20K out of 1.2M. Is it
>>>>> worth it?
>>>> In smaller foot print I guess I meant no v3 daemons, esp rpcbind.
>>>
>>> The rpcbind rpm is 120K installed, so if the new v4-only rpm has no
>>> dependency on rpcbind then we save 120K.
>> I believe it is more of a functionally thing than a size thing
>> WRT to containers.
>
> OK. But if it's not about size, then we can use "rpc.mountd -N2 -N3",
> we don't need a separate daemon.
Personally I see this is the first step away from V3...
So what we don't need is all that RPC code, all the different mounting
versions... no RPC code at all, which also means no need for libtirpc...
That is a lot of code that goes away, which I think is a good thing.
I never thought it was a good idea to have mountd process
the v4 upcalls... I always thought it should be a different
deamon... and now we have one.
A simple daemon that only processes v4 upcalls.
steved.
On Thu, Mar 04, 2021 at 08:57:28AM -0500, Steve Dickson wrote:
> Personally I see this is the first step away from V3...
>
> So what we don't need is all that RPC code, all the different mounting
> versions... no RPC code at all, which also means no need for libtirpc...
> That is a lot of code that goes away, which I think is a good thing.
libtirpc is a shared library, it'll still be loaded as long as anyone
needs it, and I'm not convinced we'll be able to get rid of all users.
> I never thought it was a good idea to have mountd process
> the v4 upcalls... I always thought it should be a different
> deamon... and now we have one.
>
> A simple daemon that only processes v4 upcalls.
I really do get the appeal, I've always liked the idea too.
I'm not sure it's bringing us a real practical advantage at this point,
compared to rpc.mountd, which can act either as a daemon that only
processes v4 upcalls or can do both, depending on how you start it.
--b.
On 3/4/21 9:06 AM, J. Bruce Fields wrote:
> On Thu, Mar 04, 2021 at 08:57:28AM -0500, Steve Dickson wrote:
>> Personally I see this is the first step away from V3...
>>
>> So what we don't need is all that RPC code, all the different mounting
>> versions... no RPC code at all, which also means no need for libtirpc...
>> That is a lot of code that goes away, which I think is a good thing.
>
> libtirpc is a shared library, it'll still be loaded as long as anyone
> needs it, and I'm not convinced we'll be able to get rid of all users.
>
>> I never thought it was a good idea to have mountd process
>> the v4 upcalls... I always thought it should be a different
>> deamon... and now we have one.
>>
>> A simple daemon that only processes v4 upcalls.
>
> I really do get the appeal, I've always liked the idea too.
>
> I'm not sure it's bringing us a real practical advantage at this point,
> compared to rpc.mountd, which can act either as a daemon that only
> processes v4 upcalls or can do both, depending on how you start it.
Right with some configuration changes... But I do think there is
value with have a package that will work right out of the box!
Boom! Install the package and you have a working v4 server
with no configure changes... I do think there is value there.
steved.
On Thu, Mar 04, 2021 at 11:31:53AM -0500, Steve Dickson wrote:
>
>
> On 3/4/21 9:06 AM, J. Bruce Fields wrote:
> > On Thu, Mar 04, 2021 at 08:57:28AM -0500, Steve Dickson wrote:
> >> Personally I see this is the first step away from V3...
> >>
> >> So what we don't need is all that RPC code, all the different mounting
> >> versions... no RPC code at all, which also means no need for libtirpc...
> >> That is a lot of code that goes away, which I think is a good thing.
> >
> > libtirpc is a shared library, it'll still be loaded as long as anyone
> > needs it, and I'm not convinced we'll be able to get rid of all users.
> >
> >> I never thought it was a good idea to have mountd process
> >> the v4 upcalls... I always thought it should be a different
> >> deamon... and now we have one.
> >>
> >> A simple daemon that only processes v4 upcalls.
> >
> > I really do get the appeal, I've always liked the idea too.
> >
> > I'm not sure it's bringing us a real practical advantage at this point,
> > compared to rpc.mountd, which can act either as a daemon that only
> > processes v4 upcalls or can do both, depending on how you start it.
> Right with some configuration changes... But I do think there is
> value with have a package that will work right out of the box!
>
> Boom! Install the package and you have a working v4 server
> with no configure changes... I do think there is value there.
Installing rpms and enabling systemd units is also a form of
configuration.
So maybe it comes down to whether we'd rather configure a v4-only server
with:
dnf install nfsv4-only-server
systemctl enable nfsv4-server
vs.
edit some stuff in /etc/nfs.conf
My preference is for the second, but it's just a feeling, I don't really
have an objective argument either way. Anyone else?
--b.
> On Mar 5, 2021, at 9:36 AM, J. Bruce Fields <[email protected]> wrote:
>
> On Thu, Mar 04, 2021 at 11:31:53AM -0500, Steve Dickson wrote:
>>
>>
>> On 3/4/21 9:06 AM, J. Bruce Fields wrote:
>>> On Thu, Mar 04, 2021 at 08:57:28AM -0500, Steve Dickson wrote:
>>>> Personally I see this is the first step away from V3...
>>>>
>>>> So what we don't need is all that RPC code, all the different mounting
>>>> versions... no RPC code at all, which also means no need for libtirpc...
>>>> That is a lot of code that goes away, which I think is a good thing.
>>>
>>> libtirpc is a shared library, it'll still be loaded as long as anyone
>>> needs it, and I'm not convinced we'll be able to get rid of all users.
>>>
>>>> I never thought it was a good idea to have mountd process
>>>> the v4 upcalls... I always thought it should be a different
>>>> deamon... and now we have one.
>>>>
>>>> A simple daemon that only processes v4 upcalls.
>>>
>>> I really do get the appeal, I've always liked the idea too.
>>>
>>> I'm not sure it's bringing us a real practical advantage at this point,
>>> compared to rpc.mountd, which can act either as a daemon that only
>>> processes v4 upcalls or can do both, depending on how you start it.
>> Right with some configuration changes... But I do think there is
>> value with have a package that will work right out of the box!
I didn't understand this claim. Don't we already have that?
If not, why not?
>> Boom! Install the package and you have a working v4 server
>> with no configure changes... I do think there is value there.
>
> Installing rpms and enabling systemd units is also a form of
> configuration.
Don't understand this argument either. What does "with no
configuration changes" mean exactly? Installing and enabling
is, as Bruce says, about the same administrative hassle as
editing /etc/nfs.conf. What's being avoided here?
> So maybe it comes down to whether we'd rather configure a v4-only server
> with:
>
> dnf install nfsv4-only-server
> systemctl enable nfsv4-server
>
> vs.
>
> edit some stuff in /etc/nfs.conf
>
> My preference is for the second, but it's just a feeling, I don't really
> have an objective argument either way. Anyone else?
Now, I'm making these comments in good faith. I don't want
Steve to roll his eyes and think "what a pain in the ass".
Please read and digest. Maybe have a Scotch and get a good
night's sleep before replying. I really really don't want
an argument, especially not right before a weekend. (And
note please that I've given some alternatives here, so I'm
not just trying to knock down the ideas).
I feel strongly that the first approach is wrong, but it's
Steve's ballgame so I'm not going to go as far as a NAK.
We've spent a decade trying to fix the mistake of having an
"nfs" and "nfs4" filesystem type on the client. Now we want
to do the same thing on the server, and in the end, if and
when NFSv3 goes away, we will be stuck with nfsv4-only-server.
All I'm saying is we should proceed very carefully so we
don't paint ourselves into a corner in the long run. This
game is ultimately about lowering long-term maintenance cost.
First, if only NFSv4 is configured in /etc/nfs.conf, then
just don't start rpcbind. We already do this for statd when
NFSv2 or NFSv3 is mounted on an NFS client. Let's automate
and hide as much complexity as possible.
Second, "dnf install nfsv4-only-server" by itself makes sense
if you want to remove rpcbind and a few other components that
are not ever going to be used, and you want to prevent dnf
from ever installing them again during an update.
But instead of nfsv4-only-server I might consider splitting
the RPM generated by nfs-utils.src: one called nfs4-utils
that installs the nfsv4-only stuff, and nfs-utils, which
depends on nfs4-utils and installs the non-v4 stuff too. No
changes to systemd units, please! And "dnf install nfs-utils"
as before still provides the whole user space suite.
Folks who just want an NFSv4 server can uninstall nfs-utils
and install nfs4-utils (or if nothing is on the system, just
install nfs4-utils). The configuration steps, and this is
critical, are otherwise exactly the same in both cases.
Third, as for exportd... if we're not changing the upcall
mechanism, then just having mountd not start network listeners
seems entirely adequate. I don't see the sense in replacing
it.
If you want smaller binaries, then let's focus on putting
the whole nfs-utils package on a diet. Everyone wins that
way.
--
Chuck Lever