Scott Lystig Fritchie
Fri Apr 26 06:24:57 CEST 2002
>>>>> "hs" == Hal Snyder <hal@REDACTED> writes:
hs> Miguel Barreiro Paz <enano@REDACTED> writes:
>> The problem with NFS is that upon network failures tends to behave
>> in rather unpredictable ways, [...]
hs> All too often, NFS turns small failures into large ones. And it
hs> thereby introduces a single point of failure into a nicely
hs> distributed OTP system, no?
No. At least, not the OTP system that I worked on at my last gig.
But then again, we implemented the NFS client in Erlang and chose
quite intentionally not to implement the braindamaged behavior that
most UNIX kernels have evolved and that no one (myself included) has
bothered To Do a Better Way. :-)
To be fair, that work also meant making the applications aware that
their "disk" operations might fail. Many developers treat the file
system like the ancients regarded fish in the sea: it's just there.
Developers that do check file op errors almost never do it with the
mindset of, "Oh, that one might be only temporary." So, most UNIX
flavors try to hide from user space apps the funky & weird things can
(and do) happen regularly to networks. The mishmash result, without a
Having said all that malicious and quite true stuff about kernel NFS
client implementations ... If you have decent & sane ways of dealing
with network errors, there are several NFS servers that have had
dozens of person years spent on them to be able to move huge amounts
of data across a network very quickly....
More information about the erlang-questions