zlacker

[return to "NFS: The Early Years"]
1. mangix+5h[view] [source] 2022-06-21 01:01:20
>>chmayn+(OP)
Isn't SMB better than NFS?
◧◩
2. colord+Vs[view] [source] 2022-06-21 02:39:11
>>mangix+5h
It at least doesn't lock anything up that has a file open when the network goes down. NFS is a nightmare with that. NFS is more idiomatic on *nix but still a huge pain when dealing with matching file perms across systems.
◧◩◪
3. dikei+mv[view] [source] 2022-06-21 02:56:39
>>colord+Vs
> It at least doesn't lock anything up that has a file open when the network goes down. NFS is a nightmare with that.

Yeah, we've been bitten by this too, around once a year, even with our fairly reliable and redundant network. It's a PITA, your process just hang and there's no way to even kill it except restarting the server.

◧◩◪◨
4. trasz+N81[view] [source] 2022-06-21 08:47:38
>>dikei+mv
This sounds like a Linux client bug (failure to properly implement the “intr” mount option), not the fault of NFS itself.
◧◩◪◨⬒
5. grossw+Nc1[view] [source] 2022-06-21 09:31:43
>>trasz+N81
It’s a failure to use the intr mount option. I’ve never had a problem using soft mounts either, which make the described problem non existent
◧◩◪◨⬒⬓
6. jabl+Vh1[view] [source] 2022-06-21 10:31:32
>>grossw+Nc1
intr/nointr are no-ops in Linux. From the nfs(5) manpage (https://www.man7.org/linux/man-pages/man5/nfs.5.html ):

> intr / nointr This option is provided for backward compatibility. It is ignored after kernel 2.6.25.

(IIRC when that change went in there was also some related changes to more reliably make processes blocked on a hung mount SIGKILL'able)

[go to top]