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?Thanks~!
Will the execution of the binaries that is sitting on a mounted NFS directory fails when network interruption happen?
linux;filesystems;nfs;open files;dynamic loading
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).