Request: NFS support

[ghost]

The MiSTer having Linux under the hood, I was surprised to find out that kernel support for NFS isn't compiled in. While CIFS works, it's a very round about way to work for a Linux system. I'd rather not deal with Samba on my server system if it can be avoided. Compiling in support is no more than a single line in the kernel config.

If this gets an OK, I can start working on scripts that make it work in similar ways to the current CIFS implementation.

[fooness]

NFS support would be absolutely terrific. Please let’s make this happen.

Maybe this forum thread should be linked here: https://misterfpga.org/viewtopic.php?t=2821

I wonder why none of the other commenters — besides @basvandewiel — enganged here before.

And by the way: Thank you for your amazing work, @sorgelig.

[sorgelig]

No problem @basvandewiel, addon scripts are fine. Support can be compiled in. Booting with NFSd service for everyone isn't a good idea as it will additionally slow down the start. So starting by request is way to go.

[ghost]

Hello @sorgelig I spent some time over the past few days to hammer out some scripts. I'm reluctant to drop a custom-built kernel on my own MiSTer but things should work (functions just fine on my laptop and RPi). No running processes are required on the MiSTer side of things, so no daemons whatsoever. Only kernel support is needed. The script currently does the following:

• Sanity checks
• Mount the NFS-share to /tmp/nfs_mount
• Create bind-mounts into /media/fat for anything it finds on the server, leaves everything else alone.
• Optionally: drop scripts into /etc/network/if-up.d and /etc/network/if-down.d to handle mounting at every reboot.

If you could be so kind to update the main kernel image to enable the NFS bits on that side, I can start testing in earnest and hope to eventually upstream my script into the main project.

The repo is here: https://github.com/basvandewiel/misternfs

[sorgelig]

You can test on this:
https://www.mediafire.com/file/sr5u1x7b94oag6m/test2.7z/file

[ojaksch]

May I throw my hat into the ring?
I'm building my own NFS Kernel for MiSTer, based upon this repo but NFSv4 aware, since 1.5 yrs after every release and publish it on the above mentioned thread for testing and everyone's joy.

NFSv3 is rather old but usually needed for commercially NAS systems, however NFSv4 is way more modern and I'm sure that everyone is using it when one is running a modern distribution for NFS shares / a NAS.

Kernel options I'm additionally using:

• CONFIG_PNFS*
  Maybe beyond everyones NFS shares for MiSTer and maybe could be left off
  https://linux-nfs.org/wiki/index.php?title=Configuring_pNFS/spnfsd&oldid=5160
  https://www.snia.org/sites/default/orig/DSI2014/presentations/StorTech/AlexMcDonald_Practical_Steps_Implementing_NFSv41.pdf
• CONFIG_NFS_FSCACHE
  Useful for recurring access to NFS files, but may constrain MiSTer's memory
• CONFIG_NFS_USE_KERNEL_DNS
  Enabled for NFSv4
• CONFIG_NFS_V4_2_SSC_HELPER
  Automatically selected when NFSD_V4 is enabled
• CONFIG_NFS_DISABLE_UDP_SUPPORT
  From fs/nfs/Kconfig: NFS over UDP on modern networks (1Gb+) can lead to data corruption caused by fragmentation during high loads.
  Defaults to yes.

If discussed and/or accepted, I'd create a PR for this.

[ghost]

NFSv4 is ~20 years old by now. Any NAS worth its salt supports it. The mount scripts as they stand now also assume it. The main point of contingency here would be the cache flag. If it does RW-caching (not sure if it does) I'd be against enabling it because MiSTer probably never gets a truly clean shutdown from many of its users and corruption will ensue.

With speed of IO hardly being a problem for the retro computers we simulate (contemporary IDE drives effectively clocking in at little more than a 10Mbps LAN link), I lean towards disabling the cache flag.

It should also be clear that these changes do not require MiSTer to run any daemons. The nfsd is only needed to run a server, which the MiSTer shouldn't try to do out of the box IMHO.

[ojaksch]

I'm also unsure if nfs_cache supports RW, but I think it does ... otherwise it would make little sense.
Therefore, and because of the fact that users simply turn off MiSTer when finished playing, I'd also vote to disable CONFIG_NFS_FSCACHE.

[ghost]

The docs are quite iffy on the actual functioning of CONFIG_NFS_FSCACHE but it seems to require an additional daemon on the MiSTer to do anything. I say skip it. Same for the pNFS support. The use of NFS SSC is also not something MiSTer will use, but is required for the ability to use NFSv4.2 as a protocol. There probably won't be a NFSv4.2-only server in the wild anytime soon. With the network security posture of MiSTer as a whole in mind (full root access, default passwd etc), I'd say skip it as well for at least the next decade.

My guiding principle when building anything is to reducing moving parts, so skip as much as possible.

@ojaksch I don't have the scaffolding in place to cross-build a MiSTer kernel. Could you figure out the minimal set of changes required for the MiSTer to connect to an NFSv4 server and submit a PR for just that and leave the NFSv3 bits in place? I'll look into integrating a toggle for that into the scripts for those working off ancient NAS boxes.

[ojaksch]

config_patch.zip
I have tried to disable CONFIG_PNFS* but doesn't work. Looks like it is a fixed part/dependency of NFSv4 and auto-reenabled when compiling. And CONFIG_NFS_V4_2_SSC_HELPER hasn't selectable option in menuconfig so I'd leave this as it is.
This would result in the attached .config patch (which would become arch/arm/configs/MiSTer_defconfig in the source tree then)

[ghost]

@ojaksch could you maybe "teach me to fish" and get me going with a local build environment for MiSTer kernels? I have an x86_64 laptop with Arch Linux that I'm working from that'd be the best candidate. Haven't built a Linux kernel in over a decade, let a lone cross-compiled one, so I'm a bit rusty there.

[ojaksch]

Yep, will do this tomorrow. I'm somewhat drunk now ;) But as you also are using ArchLinux like me, this will be an easy task.

[ojaksch]

There are two entries in the Wiki:
https://github.com/MiSTer-devel/Wiki_MiSTer/wiki/Compiling-the-Linux-kernel-for-MiSTer
https://github.com/MiSTer-devel/Wiki_MiSTer/wiki/ARM-cross-compiling

But in short:

• Get the Kernel for MiSTer
  git -C /tmp clone https://github.com/MiSTer-devel/Linux-Kernel_MiSTer
• Get the ARM toolchain and decompress it to somewhere, e.g. /opt
  wget -c https://releases.linaro.org/components/toolchain/binaries/6.5-2018.12/arm-linux-gnueabihf/gcc-linaro-6.5.0-2018.12-x86_64_arm-linux-gnueabihf.tar.xz
• Set variables for the toolchain
  export ARCH=arm EXTRAVERSION=-MiSTer CROSS_COMPILE=/opt/gcc-linaro-6.5.0-2018.12-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-
• Enter Kernel's directory
  cd /tmp/Linux-Kernel_MiSTer
• Load default Kernel config
  make MiSTer_defconfig
• Edit .config file as necessary (or skip this step and copy over / use my .config file)
• After saving your changes, start the build process
  make savedefconfig && make LOCALVERSION="-MiSTer" zImage && make socfpga_cyclone5_de10_nano.dtb && cat arch/arm/boot/zImage arch/arm/boot/dts/socfpga_cyclone5_de10_nano.dtb > zImage_dtb
  (If you're using a multicore system (and I'm sure you are), use them when compiling by setting -j<NumOfCores> so the line above reads ... make -j8 LOCALVERSION= ...

Voila, you'll find your own baked Kernel as zImage_dtb.