So I have a Linux machine that acts as an NFS server. Lots of programs has been installed to the folder that is being exported.

On another Linux machine, I've been running one of the program that is sitting in the exported NFS folder for a very long time, and it won't finish soon.

It turns out that now I need to do some urgent maintenances work with the network, so the network will be down for a while.

I'm wondering what will happen to the running program?

My understanding is that the program is loaded to the RAM in a lazy approach. So in the best case, say the program is executing some codes that is a part of loop that has been already loaded into the RAM, then it won't need to access the executable file at all during the period of network interrupt, and the program will just keep executing fine, like nothing happened, right?

But, say that, if it turns out that the program do need load some other parts of the executable into the RAM and the network is currently down. Will it "freeze" for a while and then continue to execute fine when the network is up?

I'm thinking of this loading process will eventually invoke some io related system call, and those system call will eventually handled by the NFS client library. If the network is down, then NFS client library will just keep retrying for the time period the network is down and then return success when the network is up. So from the perspective of the system, this just seems like a system call takes a really long time.

I'm not sure about my reasoning, especially for the part of the loading process. When loading a part of the executable into the RAM, will the OS invoke the io related system call? Or can it bypass the system call and do it in a even lower level approach and then fails, so that the execution of my program will be stop due to the failure?

Also, do I need to consider NFS caching policies in reasoning about this?


  • On the client, is the NFS filesystem mounted with the "hard" option or the "soft" option? – Mark Plotnick Sep 8 '16 at 23:07
  • it is mounted as hard~ so it should be able to continue to execute when the network is up, right? To the program or to the kernel, it should just looks like an io operation that takes a very long time? – D-Glucose Sep 9 '16 at 5:22
  • Yes, things should be fine as long as your network maintenance is just an interruption. But if any reconfiguration is done - for example, the server changes IP address and a different server acquires the same address - the i/o operations could fail. – Mark Plotnick Sep 9 '16 at 5:46

Your understanding is not exactly correct, but it's pretty close. The program is indeed loaded lazily, page by page. (Some of it may in fact be loaded before use, but that's a performance-memory trade-off, not something you can count on.)

The part of the system that does the loading is the kernel itself. A page is loaded at the latest when the program requires that piece of memory, either to access data or to jump to a machine instruction. The way this works is that each memory access in the processor goes through the MMU; if the page containing the requested access is mapped in the process's MMU table then the CPU simply accesses the memory; if the page is not mapped then this triggers a trap which executes a piece of code in the kernel that analyzes the reason for the trap, allocates a page of physical memory, loads the required page content and returns control to the program to perform the access again.

When a memory page has been modified by the program, its content may be placed in swap and then loaded back. When a memory page comes directly from a file (executable or not), its content is loaded from that file. This doesn't go through system calls since it's all happening inside the kernel, but it makes the same low-level accesses that a system call to access a file would do.

The upshot is that if the filesystem where a running executable is stored becomes inaccessible, then the process will hang. It will remain in uninterruptile sleep until the filesystem serves the request.

If the executable is on NFS and the NFS filesystem is mounted with the hard option then the executable will wait forever or until the server replies, whichever comes first. If the NFS filesystem is mounted with the soft option then the NFS request will fail after a timeount, and this translates into a signal for the process (SIGSEGV, i.e. segfault, I think).

  • So, when a user space program want to access a file, it needs to invoke the system call such as open() and read(), and the system call will interrupt or trap, then the handler in the kernel space take over the control. But when the kernel needs to load a page into RAM, it bypass the system call and directly invoke the handler. But in both case, the request is eventually handed over to the NFS client library, correct? – D-Glucose Sep 9 '16 at 5:19
  • @D-Glucose System calls are the interface for programs to call the kernel. The kernel doesn't so much “bypass” system calls as just make internal calls to another part of the kernel. The “NFS client library” is a part of the kernel. – Gilles Sep 9 '16 at 10:41

if your program do not try to access any file from the NFS share will continue to work .It will be fine if it do not need to read or write to a file from the NFS shared folder.

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.