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

[glen herrmannsfeldt]

Johnny Billquist <bqt at softjar.se> wrote:

(snip)
> *Yes* Despite different source code. This is not a "bug" in the source 
> code. This is an effect of the semantics of the system. It is this way 
> by design, not accident.

(snip)

> NFS essentially tries to give the same guarantees as a local disk based 
> filesystem. Local disk based filesystems don't "fail", except for 
> physical I/O errors that are not recoverable. NFS was designed in a way 
> that would allow it to continue if the server went down, and then came 
> up again. Thus, if you are doing an operation on an NFS filesystem and 
> the server is not responding, NFS will hang and retry until the server 
> do respond again. And this is not interruptable in any way normally. You 
> can give options to mount to tell it to not hang, and allow interrupts 
> for hanging NFS calls, but that instead means that you can silently get 
> data corruption, so just about anyone will tell you to not use those 
> options.

I agree, don't use them. Never have, never will.

> At the lower layers inside Unix (any Unix, I'd say), you cannot even 
> pass an error from something that have a file system semantics, that 
> will translate into EINTR at the user level. Since local disk like 
> devices are normally expected to always return within a very short time 
> with data, so they are not required to be interruptable.

Well, yes, but if the disk did take longer, you would still want
to wail. If you power-down an external drive, the system will
likely also wait for it to come back.

I do remember once, wanting to net boot a system that actually
did have a disk, starting the boot and then powering on the disk.
As well as I remember, there wasn't an option to tell it to net boot
when there was an attached disk.

> (You have a similar effect with tape drives, where your user program can 
> hang for several minutes if the tape drive is doing some slow operation, 
> since tape drivers also are non-interruptable, and you are in fact down 
> in a protected piece of code deep in the kernel, that Unix cannot back 
> out of, or complete until the device have responded.)

-- glen