>>>>> " " == Mark H Johnson RTS <Mark_H_Johnson.RTS@raytheon.com> writes:
> Just to recap & make sure I have this straight.
> (2) IF I'm dealing with NFS mounted files, all bets are
> off. Please confirm
> that I should take some action (e.g., remount the volume) to
> make sure the state is purged after the updates are made.
No. NFS should be in any case quite able to detect the changed file
automatically, and indeed for most sane methods of updating files
(GNU/BSD install, ...), you'll end up with an executable which will
have a new inode number, NFS file handle, . Quite safe...
You should, however, make sure that you stop and then restart any
existing processes that may be running the executable you're updating,
since they are liable to crash whenever we need to page something in
afresh (assuming that the original executable was indeed deleted on
the NFS server, and not just renamed).
In case it wasn't clear: The point made in my mail to Andrea was
directed at a specific patch in which he purported to fix a VM problem
with our handling of mmapped files, but which I believe will break the
current correct behaviour on generic file updating over NFS, and will
also lead to new problems with mmapped files.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:17 EST