Re: NFS alternative
On 17 Jul 2001, Brian May wrote:
[...]
> I have heard though, that NFS uses RPC, and RPC doesn't do anything
> this sophisticated. Rather, if the server doesn't respond in time, the
> client sends the request again.
>
> This is OK for requests like "read file", which don't affect the state
> of the server, as the worst thing that could happen is that the server
> will reread the file again.
>
> For other requests though, like "delete file", confusion could
> occur. eg. consider the case where the client wants to delete file X,
[...]
Well, of course you can bet that all these issues have been taken
into account in the design of the NFS protocol.
But actually this touches an important aspect of NFS servers: by
design/philosophy they are stateless. This means that the NFS server can
crash, reboot, and to the client it makes strictly no difference (the
same goes for the client). And this fits well with UDP since it's a
connectionless protocol.
Compare this to the SMB protocol used by Windows. This protocol is
resolutely stateful. And guess what: SMB uses TCP connections. So if the
server crashes then the clients have to reconnect to the server and try
to resynchronize their state with the state of the server somehow. Well,
of course, the designers of the SMB protocol thought of the issue too
and I'm sure it's all taken care of.
Now, you are worried that if an NFS UDP packet is lost you'll get
into trouble. But what if an SMB client sends an 'append' command to the
server, the server performs the operation but crashes before sending the
reply, reboots, causing the client to reconnect and resend the
command... You see, using TCP did not save you completely. You get
exactly the same problem as if the NFS server had crashed and rebooted,
or the command packet got lost, or the reply packet got lost. I believe
that the work to recover from such problems must be relatively
equivalent in both cases.
Btw, I doubt that there is an 'append' command as it is so obviously
not 'idempotent'. Of course there must be some sort of 'delete_file'
operation and I'm not sure how them make that one 'idempotent'. But in
multi-user systems how do you know if the file was not deleted by some
other user in the first place...
> Conclusion: (if my sources are correct) never use NFS (unless mounted
> read-only) over a congested network...
I think you need to do some reading.
I don't know of a reference book that would be specifically about NFS
but you can have a look at "The Design and Implementation of the 4.4BSD
Operating System" by McKusik, Bostic, Karels and Quarterman. Chapter 9
(about 25 pages) is about NFS and should give you a feel for it. And the
book as a whole is just awsome. Definitely a must have if you're
interested in operating system design.
I'm definitely going to re-read this chapter...
--
Francois Gouget fgouget@free.fr http://fgouget.free.fr/
1 + e ^ ( i * pi ) = 0
Reply to: