3 ms·

Is it common to build over NFS? I can't immediately see a use case - collaborative editing or something? Even in that case, wouldn't it be easier to build on th

Is it common to build over NFS? I can't immediately see a use case - collaborative editing or something? Even in that case, wouldn't it be easier to build on the box? The other case seems valid in a sort of 'if your build intentionally makes use of mtime, you'll need to look at mtime'. It seems like an odd thing to do in the first place - I guess Makefile as deployment rather than for building? A 470K LoC project I have here with >1000 files takes 0.04 seconds to do a full sha256sum traversal on my box from the cache. That's single-threaded. If I drop caches, it takes approximately 1 second (from spinning rust, not SSD).

erik_seaberg 8y ago
NFS is getting so rare that some systems aren't even organized to accommodate "mount -o ro /usr" anymore.
- esotericn 8y ago
  I use NFS a decent amount, just not for anything like this, because even on a link with e.g. 5ms latency you end up with issues all over the place. It seems like solving a problem that could be fixed more easily by just rsyncing or cloning the codebase. Storage is cheap.
- ams6110 8y ago
  NFS is widely used in HPC to mount user home directories on compute nodes.
__float 8y ago
At work, we frequently build in a Linux VM (using VirtualBox through Vagrant) from a macOS host, and the default shared folder does not support symlinks. We use NFS as a workaround.
livueta 8y ago
I do a lot of nfs builds at work as part of development on a proprietary OS. Some things will only nicely build on-OS, which for dev purposes is generally running in a non-local VM. The relevant git repos are massive enough (I'll frequently be building a small part of the tree, but still have to clone the whole thing), and the VMs disposable enough, that dealing with slower builds via an nfs mount from my workstation and/or homedir server is faster than repeatedly cloning. You can probably argue that this is a consequence of bad tooling rather than any strength of nfs builds, but it is an example of a non-trivial number of developers frequently building over nfs.
koala_man 8y ago
For the median project, you could just rebuild everything from scratch every time and avoid the problem. It's the huge projects with millions of files and tens of gigabytes of source and assets that need these optimizations the most, and that's also where checksumming is the most painful. It's not as unrealistic or monstrous as it sounds. It happens in monorepos when you include all of a project's thousand dependencies (down to things like openssl and libpng).

erik_seaberg 8y ago

NFS is getting so rare that some systems aren't even organized to accommodate "mount -o ro /usr" anymore.

esotericn 8y ago
I use NFS a decent amount, just not for anything like this, because even on a link with e.g. 5ms latency you end up with issues all over the place. It seems like solving a problem that could be fixed more easily by just rsyncing or cloning the codebase. Storage is cheap.
ams6110 8y ago
NFS is widely used in HPC to mount user home directories on compute nodes.

__float 8y ago

At work, we frequently build in a Linux VM (using VirtualBox through Vagrant) from a macOS host, and the default shared folder does not support symlinks. We use NFS as a workaround.

livueta 8y ago

I do a lot of nfs builds at work as part of development on a proprietary OS. Some things will only nicely build on-OS, which for dev purposes is generally running in a non-local VM. The relevant git repos are massive enough (I'll frequently be building a small part of the tree, but still have to clone the whole thing), and the VMs disposable enough, that dealing with slower builds via an nfs mount from my workstation and/or homedir server is faster than repeatedly cloning. You can probably argue that this is a consequence of bad tooling rather than any strength of nfs builds, but it is an example of a non-trivial number of developers frequently building over nfs.

koala_man 8y ago

For the median project, you could just rebuild everything from scratch every time and avoid the problem. It's the huge projects with millions of files and tens of gigabytes of source and assets that need these optimizations the most, and that's also where checksumming is the most painful. It's not as unrealistic or monstrous as it sounds. It happens in monorepos when you include all of a project's thousand dependencies (down to things like openssl and libpng).