[Info-vax] Current VMS engineering quality, was: Re: What's VMS up to these

[John Wallace]

On Mar 15, 11:08 pm, Johnny Billquist <b... at softjar.se> wrote:
> On 2012-03-15 15.34, glen herrmannsfeldt wrote:
>
> > Johnny Billquist<b... at softjar.se>  wrote:
>
> > (snip regarding NFS mounts of disks that go away.)
>
> >>> In general, Unix doesn't do much file locking, and, yes the NFS
> >>> implementation is especially troublesome.
>
> >> Indeed. But it is worse. For example, if a file is opened for execution,
> >> Unix prevents you from writing to that file.
>
> > Not on systems that I used. Which ones do that?
>
> Linux and NetBSD at least. Can't remember if I've tried on others...
>
> Example run, with a local copy of sleep (on a Linux system):
>
> gazonk:/tmp> ./foo 1m &
> [2] 19490
> gazonk:/tmp> cat > foo
> foo: Text file busy.
> gazonk:/tmp>
>
> Exactly the same results with NetBSD.
>
> The error code is ETXTBSY
>
> To quote the man-page:
>       26 ETXTBSY Text file busy.  The new process was a pure procedure
> (shared
>               text) file which was open for writing by another process, or
>               while the pure procedure file was being executed an
> open(2) call
>               requested write access.
>
> >> This semantic is also lost if the file is accessed over NFS,
> >> meaning you can write to a binary that is being executed,
> >> causing the memory of that executable to randomly
> >> corrupted at execution time, depending on when/if page in
> >> from the binary happens.
>
> > That does happen.
>
> Indeed. Unix networking just working without problems... Yeah right...
>
> >>> I am not sure exactly how much has to change. If something relating
> >>> to the specific disk changes, then yes.
>
> >> No. It's basically if anything appears different in the hardware
> >> configuration. Enumeration of devices are a part of NFS, and if that
> >> enumeration is suspected to have changed, then all old file handles
> >> are invalidated. Note that it does not necessarily have to have
> >> changed, it's just the suspicion that it has changed that is
> >> enough to trigger this.
>
> > It is likely different on different systems. I am pretty sure
> > that I did some changes where they didn't go stale, and others
> > where they did.
>
> It most probably is. After all, the basic problem is that the server
> must know that file handles are still valid in order to accept them. If
> it can be clever about it, it can be more forgiving. So it all depends
> on the server. There are no guarantees on how this works. Every
> implementation does its own thing.
>
>         Johnny

NFS was originally stateless by design. Fundamentally that means any
server has no way of knowing what its client is up to, all it can do
is serve up the requested blocks.

The server cannot know whether the client still has a file open or
not. That has advantages and disadvantages.

After 15 years of statelessness being an advantage, the NFS people
finally decided in NFS v4/RFC3530 (2003) that statelessness was A Bad
Thing and that NFS ought to have state awareness. Why so? Because
"Windows clients need state awareness" was the excuse. UNIX apps
already had decades-old workarounds for the lack of locking on UNIX.

Odd that.