[leaf-devel] Bering-uClibc as an NFS file server - Observations / Implications

[davidMbrooke <dmb...@nt...>]

Hi everyone,

I recently implemented a file server machine running Bering-uClibc
3.1-beta1 and I've been successfully using it to serve diskless Linux
clients via the iSCSI protocol (iscsid.lrp). I recognize that SAMBA and
FTP server packages are available but most of my client machines run
Linux and for them NFS is the natural choice as a file sharing protocol.
I'm new to Buildtool so I thought using that to compile some NFS server
packages would help me understand how Buildtool works.

The good news is that I've got an NFS server working on Bering-uClibc
3.1-beta1 via a couple of new .lrp packages (for portmap and nfs-utils);
the bad news is that it needed some minor changes to both uClibc and the
kernel. I'm wondering whether there's any possibility of getting those
changes incorporated into the standard Bering-uClibc configuration - if
not it won't be possible for other people to install the new .lrp files
without also recompiling the kernel and uClibc.

First the kernel: there's NFS server code shipped as part of the kernel
source but it's not configured as part of the default build. The nfsd.o
module needs to be built, and that should support both NFS v3 and NFS
over TCP. Running "make config" in the kernel source directory and
selecting the appropriate options resulted in the following changes to
the kernel .config file:

    1519c1519
    < CONFIG_NFS_V3=y
    ---
    > # CONFIG_NFS_V3 is not set
    1522,1524c1522,1524
    < CONFIG_NFSD=m
    < CONFIG_NFSD_V3=y
    < CONFIG_NFSD_TCP=y
    ---
    > # CONFIG_NFSD is not set
    > # CONFIG_NFSD_V3 is not set
    > # CONFIG_NFSD_TCP is not set
   1527d1526
    < CONFIG_LOCKD_V4=y

(I thought I'd enable NFS v3 for the NFS client code (module nfs.o) as
well as the server, hence the change to CONFIG_NFS_V3. I didn't
explicitly specify CONFIG_LOCKD_V4 but that gets set automatically with
the NFS V3 selections.)

The resulting compressed kernel file is 4 bytes shorter. The nfsd.o
module is 83163 bytes, but only relevant to anyone building a file
server.


Then there's the issue of uClibc: both the NFS rpc.mountd daemon and the
RPC portmap daemon need to call svctcp_create() and svcudp_create()
which are included in the source for uClibc but not configured as part
of the build. These can be included by selecting "full" RPC support,
with the following change to the uClibc .config file:

    99c99
    < UCLIBC_HAS_FULL_RPC=y
    ---
    > # UCLIBC_HAS_FULL_RPC is not set

The resultant libuClibc-0.9.28.so file is 16704 bytes larger than the
standard one. I guess that might be an issue, in terms of fitting onto a
floppy disk. Could we move to having a couple of variants of uClibc -
one optimized to be as small as possible and another which is larger but
more comprehensive?


I'm going to continue working on the Buildtool / Buildpacket
configurations for my own purposes (they're far from complete at the
moment). I'd appreciate some advice on whether the kernel and uClibc
changes might be possible so as to make the packages useful to a wider
audience.

Thanks,

David

-- 
davidMbrooke <dmb...@nt...>