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

[Johnny Billquist]

On 2012-03-15 04.46, glen herrmannsfeldt wrote:
> Johnny Billquist<bqt at softjar.se>  wrote:
>
> (snip)
>> 1. VMS clusters did not use ethernet originally.
>> 2. Unix distributed networks using ethernet and shared disks is not
>> robust at all. You must be totally uninformed if you claim this. Have
>> you ever used a machine with an NFS root? Any time the server stopped,
>> rebooted, or whatever, all clients *freeze*. Not even rebooting, unless
>> you press the power switch. You just sit there waiting for the NFS
>> server to wake up again.
>
> I haven't done it for a while, but most often you can reboot without
> accessing the specific disk.

If the root fs is over NFS, you obviously can't...
But yes, if you can totally avoid ever accessing the NFS file system, 
then you can (hopefully) carry on.

>> 3. Unix, using NFS, is weird and unreliable. File locking does not work
>> properly.
>
> 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. 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.

>> File renaming and deletion is troublesome, and deleting a file
>> used over NFS is handled by actually not deleting the file, but instead
>> renaming it to something starting with a period, so that you don't
>> normally see it, creating the illusion that you deleted the file.
>
> That should only happen if the file is open when you delete it.

Right.

> The client should then delete the file when it is closed. If the
> client crashes before it gets to close it, the file won't be delete.

Right.

> Unix convention is that if you delete an open file, it stays around
> until closed, though the name is removed from the directory.
> It isn't possible to do that with a stateless NFS server.

Right. So when NFS gets involved, it becomes a bunch of hacks, where 
data corruption can happen (that Unix otherwise will not allow), and 
weird solutions are used to get around the different semantics in NFS.

>> Furthermore, security wise, it is a joke. You use mountd daemon to mount
>> and access NFS disks, but if you know the file handles, you can totally
>> skip the mounting, and thus also skip the permissions of the
>> /etc/exports file.
>
> I thought it was supposed to be better now, but it is best for
> local networks where you trust the users.

Yes.

>> 4. Unix does normally not crash, but instead freeze. And not only if the
>> network goes down, but also if the single machine serving the disk goes
>> down. Also, if anything in the server configuration changes, all clients
>> needs to be rebooted, no matter if the server comes back, since NFS
>> don't allow any recovery in that case. And we are talking about very
>> ungraceful rebooting here. No controlled take down. You'll have to reach
>> for the reset or power switch, since controlled shutdown is impossible.
>
> 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.

> I once sold a server while clients still had the disk mounted.
> If you are fast, you can umount before the disk is accessed, but
> otherwise, yes, reboot is the only way.

Right. As long as the unmounting itself does not imply any disk access, 
which it very well might, since you can have caching.

	Johnny