5 ms·

Do not mount NFS with "soft" unless you really know what you're doing. NFS' behavior to hang is not "stupidity" - it's actually one of the best things about NF

by agwa 14y ago

Do not mount NFS with "soft" unless you really know what you're doing. NFS' behavior to hang is not "stupidity" - it's actually one of the best things about NFS. Applications do not deal well with failed reads/writes. If there's a brief network interruption or the NFS server goes down, it's WAY safer to cause applications to hang until the server comes back. Since NFS is a stateless protocol, when the server comes back, I/O resumes as if nothing ever happened. This helps make using NFS feel more like using a local filesystem. Otherwise it becomes a very leaky abstraction. Not being able to kill processes stuck on NFS I/O is annoying though, so you can mount with the "intr" option and that makes such processes killable. However, since Linux 2.6.25, you don't even need this and SIGKILL can always kill applications stuck in NFS I/O.

NelsonMinar 14y ago
This would be a good time to re-read Waldo's "A Note on Distributed Computing", which points out how remote filesystems will never act like local filesystems. http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf
dredmorbius 14y ago
Expecting NFS (or any other remote filesystem) to behave as if it were local is a fundamental error. Time, and speed of light, ultimately matter. If you need assurance, find a way of getting reliability in your system through redundancy and locality. Distinguish between "task has been delegated" and "task has been confirmed completed". Down any other path runs pain, and anyone who tells you otherwise is selling something. You're going to have to compromise: whole systems (or clusters) going titsup because your NFS heads had a fart, or lost commits. Neither is very attractive when shit's on the line. Your database relying on NFS is a fundamental error you'll have to design around.
- jrockway 14y ago
  NFS can be faster than local storage. Compare a very slow tape drive versus a very fast 10Gbps network connection to an NFS server with a huge in-memory cache. The problem is expecting any filesystem to be reliable.
- smutticus 14y ago
  In my experience NFS is fine as long as the traffic does not need to traverse a WAN link. The problem, as I see it, is that once something is available via NFS everyone wants to mount it from everywhere. NFS simply does not deal well with high RTT connections.
  - dredmorbius 14y ago
    Good luck with that assumption. /net
- laumars 14y ago
  > Expecting NFS (or any other remote filesystem) to behave as if it were local is a fundamental error. Any storage medium is subject to fail, the issue isn't specific to remote file systems. In fact I personally consider the Plan 9 methodology towards file systems to be one of the greatest ideas it's imparted on Linux and Unix. So I'm all in favour of the local file systems, services and remote objects and file systems transparently behaving as one. > Time, and speed of light, ultimately matter. People often cite the speed of light when talking about electronics when actually electrons don't travel at the speed of light (they have mass). The difference maybe small, but using precise scientific terms imprecisely is one of my pet hates. > You're going to have to compromise: whole systems (or clusters) going titsup because your NFS heads had a fart, or lost commits. Neither is very attractive when shit's on the line. If this is a serious issue then you should be looking into iSCSI. A bad workman blames his tools, a good workman finds the best tool for the job.
  - SEMW 14y ago
    > People often cite the speed of light when talking about electronics when actually electrons don't travel at the speed of light (they have mass) Actual electrons move pretty slowly - of the order of millimetres per hour. That speed has nothing to do with the speed the signal propagates down the wire. The speed the signal is propagated is the speed the electromagnetic wavefront moves along it. Which is mostly limited by the dielectric constant of the wire's insulator. (That actually is related to the speed of light in the insulator - they both depend on its permittivity). It's not related to the speed electrons move in the wire, which depends on its cross-sectional area and the current. In particular, the fact that electrons have mass isn't relevant to the wavefront propagation speed. (C.f. fibre optic cables, which will have a wavefront propagation speed not dissimilar to copper wire (i.e. both will be a substantial fraction of c), even though, unlike copper wire, their carriers are massless and actually do move at the wavefront speed). Analogy: imagine pushing the end of a very long, rigid broomstick. The actual wood in the broomstick moves pretty slowly (maybe you move it a cm in a second). But the person at the other end feels their end of the broomstick move almost immediately, limited only by a speed of light delay (or a little more if the broomstick isn't as rigid as possible).

by agwa 14y ago

NelsonMinar 14y ago

This would be a good time to re-read Waldo's "A Note on Distributed Computing", which points out how remote filesystems will never act like local filesystems. http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf

dredmorbius 14y ago

Expecting NFS (or any other remote filesystem) to behave as if it were local is a fundamental error. Time, and speed of light, ultimately matter. If you need assurance, find a way of getting reliability in your system through redundancy and locality. Distinguish between "task has been delegated" and "task has been confirmed completed". Down any other path runs pain, and anyone who tells you otherwise is selling something. You're going to have to compromise: whole systems (or clusters) going titsup because your NFS heads had a fart, or lost commits. Neither is very attractive when shit's on the line. Your database relying on NFS is a fundamental error you'll have to design around.

jrockway 14y ago
NFS can be faster than local storage. Compare a very slow tape drive versus a very fast 10Gbps network connection to an NFS server with a huge in-memory cache. The problem is expecting any filesystem to be reliable.
smutticus 14y ago
In my experience NFS is fine as long as the traffic does not need to traverse a WAN link. The problem, as I see it, is that once something is available via NFS everyone wants to mount it from everywhere. NFS simply does not deal well with high RTT connections.
- dredmorbius 14y ago
  Good luck with that assumption. /net
laumars 14y ago
> Expecting NFS (or any other remote filesystem) to behave as if it were local is a fundamental error. Any storage medium is subject to fail, the issue isn't specific to remote file systems. In fact I personally consider the Plan 9 methodology towards file systems to be one of the greatest ideas it's imparted on Linux and Unix. So I'm all in favour of the local file systems, services and remote objects and file systems transparently behaving as one. > Time, and speed of light, ultimately matter. People often cite the speed of light when talking about electronics when actually electrons don't travel at the speed of light (they have mass). The difference maybe small, but using precise scientific terms imprecisely is one of my pet hates. > You're going to have to compromise: whole systems (or clusters) going titsup because your NFS heads had a fart, or lost commits. Neither is very attractive when shit's on the line. If this is a serious issue then you should be looking into iSCSI. A bad workman blames his tools, a good workman finds the best tool for the job.
- SEMW 14y ago
  > People often cite the speed of light when talking about electronics when actually electrons don't travel at the speed of light (they have mass) Actual electrons move pretty slowly - of the order of millimetres per hour. That speed has nothing to do with the speed the signal propagates down the wire. The speed the signal is propagated is the speed the electromagnetic wavefront moves along it. Which is mostly limited by the dielectric constant of the wire's insulator. (That actually is related to the speed of light in the insulator - they both depend on its permittivity). It's not related to the speed electrons move in the wire, which depends on its cross-sectional area and the current. In particular, the fact that electrons have mass isn't relevant to the wavefront propagation speed. (C.f. fibre optic cables, which will have a wavefront propagation speed not dissimilar to copper wire (i.e. both will be a substantial fraction of c), even though, unlike copper wire, their carriers are massless and actually do move at the wavefront speed). Analogy: imagine pushing the end of a very long, rigid broomstick. The actual wood in the broomstick moves pretty slowly (maybe you move it a cm in a second). But the person at the other end feels their end of the broomstick move almost immediately, limited only by a speed of light delay (or a little more if the broomstick isn't as rigid as possible).