5

I would like to understand how network mounted software works. For example, at my place of work, we have a software server. Each client machine (hundreds of them) automatically mounts directories from the software server on boot. For example, a program like Matlab is installed just once on the software server, but each client machine can start up an instance of Matlab.

What is going on under the hood?

Let's say I run /opt/bin/matlab and /opt/ is mounted from the software server, what happens when I press Enter to execute Matlab on a client machine? The process is on the client machine, and I've already narrowed down that there isn't any implicit or hidden file transfer (i.e. copying Matlab to my machine temporarily for that session) by running Matlab on a computer with nearly zero disk space (i.e. not enough room to transfer).

  • Since Matlab was installed on the server, how is my client computer executing it?
  • What mechanism is controlling this?
  • What is happening behind the scenes?
  • What makes you think that there's anything special going on behind the scenes? – Ignacio Vazquez-Abrams Nov 2 '13 at 4:22
  • It's probably a stupid question to experts, but as someone who grew up on only single-user Windows machines, having recently migrated to Linux, this concept of software being installed in a location other than the local system and still being executable by the local system, is just simply mindblowing. – CptSupermrkt Nov 2 '13 at 18:47
5

The technology they're using to make this happen is called NFS - Network File System. They may additionally be using another technology with NFS called automounts, specifically Autofs if it's Linux.

NFS

NFS allows folders from one machine to be accessible to another. There is nothing magical about this. There is a client and server that is facilitating this connection. When you access one of these directories that's been mounted on your system via the NFS client, calls are made from your system to relay the information regarding the directory and it's contents.

If one of the clients accesses a file within the directory, the NFS server relays the contents of this file to the NFS client too.

Autofs

Automounting is a technology that allows a client system to access a shared remote resource, such as NFS, on a temporary basis. That is to say that the NFS client system has access to this remote NFS share. But it isn't actively "using" it until someone attempts to access the shared directory. Only then does the NFS client attempt to "mount" this remote directory and its contents.

File content life-cycle

In either case there is no implicit transfer of the files to the NFS clients. That is to say they aren't physically copied to the clients in any long term way. The files are streamed to the clients when they attempt to access them. After use they're gone; they do not persist at the clients in any long term form.

Just to give you a rough idea, you could use the program strace to see some of the system calls that are made as a program runs. So, using this command for example:

$ strace echo "hello world" > afile

We could see how a file is written to the system. We could also use this form to write to an NFS mounted directory:

$ strace echo "hello world" > /home/sam/afile

Both of these traces a virtually identical.

### Local write

$ cat strace_wr_local.log 
execve("/bin/echo", ["echo", "hello world"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f80000
write(1, "hello world\n", 12)           = 12
close(1)                                = 0

### NFS write

$ cat strace_wr_remote.log 
execve("/bin/echo", ["echo", "hello world"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fbe000
write(1, "hello world\n", 12)           = 12
close(1)                                = 0

Reading is only slightly more interesting, but still basically identical.

### Local read

$ cat strace_rd_local.log 
execve("/bin/cat", ["cat", "afile"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=1761, ...}) = 0
open("afile", O_RDONLY|O_LARGEFILE)     = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
read(3, "hello world\n", 4096)          = 12
write(1, "hello world\n", 12hello world
)           = 12
read(3, "", 4096)                       = 0
close(3)                                = 0

### NFS read

$ cat strace_rd_remote.log 
execve("/bin/cat", ["cat", "/home/sam/afile"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=1771, ...}) = 0
open("/home/sam/afile", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
read(3, "hello world\n", 4096)          = 12
write(1, "hello world\n", 12hello world
)           = 12
read(3, "", 4096)                       = 0
close(3)                                = 0

Wading into the pool

If you're just generally curious about the NFS protocol you can read more about how it works here, in the section titled: NFS protocol basics. It's generally easy to get the basic concepts of how it works and there is an example of an NFS request, just to give you a general idea of how things work.

Diving deeper

If you truly want to peek behind the curtain you'll likely need to bring in a set of tools for collecting network traffic so that you can see the flowing of bits back and forth between the NFS server and one of its clients. Tools such has tcpdump or wireshark will likely be your friends in doing this deeper dive.

I would caution you to not waste your time unless you're truly the curious type, since deep dives like this require much skill and familiarity with a suite of Unix tools that I would consider only someone who has been using Unix for a dozen or so years.

This site will help you with this endeavor if you're truly curious:

  • One of the most epic answers I've ever received. Thank you for your time. This helps to clarify a lot of stuff. – CptSupermrkt Nov 2 '13 at 18:48
  • @CptSupermrkt - You're welcome and thank you for the Q. – slm Nov 2 '13 at 19:01
0

The LinuxTerminalServerProject "LTSP" and DisklessRemoteBootLinux "DRBL" are both free and open source projects that many schools and businesses use to PXE boot diskless clients. Simplifies administration labor cost and product cost. Since everything runs in RAM, the machine is much faster. If you were lucky enough to get a batch of those slow intel sata chipsets, DRBL clients accessing NFS servers proved very worthwhile. I do not have numbers, but i bet DRBL PXE booted diskless clients blow away locally booted SolidStateDrives. Speed of NFS is greater than SMB.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.