Nick LeRoy wrote:
> > Alan explained a few years ago that NFS was "stateless". Nevertheless
> > it is still a bug.
>
> Correct me if I'm wrong, but I think that it's more a bug in the NFS protocol
> than in the Linux (or Solaris, etc) NFS implementation. The problem is that
> NFS itself just doesn't pass that information along. The NFS server has no
> idea that the 'text' file is being executed, so it doesn't know that it
> should "return" ETXTBSY.
>
> Now, this might be different in NFS v3, but I'm pretty sure that this applies
> for v2, at least.
Consider the above mentioned statelessness. You can't get what you
want as long as you want a stateless server - it is simply impossible.
Your client can be tweaked so that you can't write via NFS to a
file executing on the same host - but nothing can prevent another
client from writing to that file - because the server is stateless.
A stateless server means it don't actually know if a file is
opened by anyone. The good part of this is that the server
may crash and reboot, and the client will only see a delay.
Open files will still work as soon as the server comes back up.
No state were lost in the crash - because there were no
state at all. But then you can't block writes because
you don't know that someone is executing the file.
It is not a design bug - it is a design tradeoff. A stateful
server might work if you have years of uptime or at least
no unplanned downtime. But such implementations tend to force
clients to remount if the server ever go down. That may
be really annoying if you're accessing lots of servers.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:26 EST