Can Rust builds be done in an NFS mounted volume?

#1

Hi,

I’m building a Rust crate on MacOS in an NFS mounted volume. Every so often I get a random linker error:

 = note: ld: warning: ignoring file /Volumes/{name}/target/debug/deps/{crate}-a03ab1e33164c0a8.3awrews3hivnsi2y.rcgu.o, file was built for unsupported file format ( 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked (x86_64): /Volumes/{crate}/target/debug/deps/{name}-a03ab1e33164c0a8.3awrews3hivnsi2y.rcgu.o

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I’m guessing my ignorance of proper NFS mount hygiene is the source of the problem, but there may be something about rustc, clang or ld that was not intended to work this way?

A cargo clean and a rebuild always fixes the issue but that slows down development quite a bit.

Any advice much appreciated,

Stu

#2

Hello, i’m using to build my projects in a nfs folder in linux server (openmediavault and fedora the compile machine)

it’s more slow than in a local folder but i don’t get this type of errors.

Two things can you post the configuration of the NFS server, and in the client how do you mount the folder in nfs

we have to view how the synchrony of the NFS is working in your case.

(Sorry for my english, not my first language)

#3

I’m not sure if it’s officially supported or unsupported, but Cargo does rely on having a good filesystem (with locks, hardlinks, lots and lots of small files, etc.), and NFS tends to be wonky.

It’s best if you define CARGO_TARGET_DIR to live somewhere else. I’ve also had success with replacing the folders in ./target/debug/* with symlinks to folders in /tmp/ (this way ./target/debug/exe stays where it was).

#4

The NFS volume is shared from a QNAP NAS to a MacBook Pro running MacOS 10.14.4.

On the NAS the relevant /etc/exports line I think is:

"/share/NFSv=4/stu" *(rw,nohide,async,subtree_check,insecure,no_root_squash,fsid=20b838f5f4d4aff6f5cb1da0eb27e018)

On the Mac, nfsstat reports:

$ nfsstat -m

/Volumes/stu from server:/stu
  -- Original mount options:
     General mount flags: 0x40 async
     NFS parameters: tcp,locallocks,rsize=65536,wsize=65536,rdirplus,deadtimeout=45
     File system locations:
       /stu @ vers=4 () server (192.168.1.101)
  -- Current mount parameters:
     General mount flags: 0x4000058 async,nodev,nosuid multilabel
     NFS parameters: vers=3,tcp,port=2049,nomntudp,hard,nointr,noresvport,negnamecache,callumnt,locallocks,quota,rsize=65536,wsize=65536,readahead=16,dsize=4096,rdirplus,nodumbtimr,timeo=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,deadtimeout=45,nomutejukebox,nonfc,sec=sys
     File system locations:
       /stu @ vers=4 () server (192.168.1.101)
     Current location: 0x1 0 1 0:
       /stu @ server (192.168.1.101)
     Status flags: 0x0

Thanks,

Stu

#5

Thanks – will give that a try.

I also tried earlier with an SMB mounted volume but that failed with file errors every time. I think Apple have created their own SMB client to avoid GPL licensing issues and it may be more problematic than the Samba suite.

#6

Ok, now with this information i can confirm.

you can have problems because of the async in the server and in the local mount, this augment the speed of the system, but can drive to the problems that your are viewing.

Options to mitigate the problem:

  1. Option is to the local mount do it sync, and see if the problems are less ocurrent.
  2. Option the nfs share and the local mount sync,… this is MORE slow but better for the security and i think that in this configuration you will not have this problem but all will be very SLUGISH.
#7

Thanks for the insights – will experiment with that setting and see how it goes.

Stu