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

[Johnny Billquist]

On 2012-03-16 16.48, Bob Eager wrote:
> On Sat, 17 Mar 2012 00:43:26 +0100, Fritz Wuehler wrote:
>
>> Johnny Billquist<bqt at softjar.se>  wrote:
>>
>>> 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.
>>
>> Correct. This just happened to me (facepalm) today on a modern Linux
>> system 2.6.29.something kernel. I didn't think and took my NFS box
>> offline and when my Linux client couldn't get to the mounted share
>> ..........................
>
> So, that's a Linux problem.

No. That is a general problem with all Unix systems, and is not specific 
to a certain implentation, but an effect of the whole design of Unix and 
NFS. There is no Unix anywhere that will behave any different.

>> Solution: reboot NFS box. Stupid, stupid, stupid. Can't the UNIX idiots
>> *ever* do anything correctly?
>
> UNIX is not an operating system. It's a specification, and that
> specification doesn't include NFS anyway. Sweeping generalisations don't
> help. Some systems conforming to 'UNIX' work OK in this situation, and
> some don't.

No. Not a single Unix behaves "OK" in this situation. They can't. It's a 
part of the basic design of the whole system. Or perhaps rather, a part 
of the effects of the basic design, as I'm sure they didn't 
intentionally design it with this effect in mind. But it an effect of 
the design.

Show me a single Unix system that does not work this way. I'd be very 
interested in digging into that to see what they have done to change 
this in that case.

>>> 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.
>>
>> Exactly what happened.
>
> On *your* system.

On *every* system. This story is as old as NFS itself. Long before Linux 
even existed.

>>>   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.
>
> On *your* system.

Again... See above...

>>> Oh, and by the way, these issues are not only relevant to machines
>>> having an NFS root. The same is true for any use of NFS. It's just that
>>> since the quoting reach back to "one common system disk", it boils down
>>> to the NFS root in Unix land.
>
> If you can define UNIX land to be all systems conforming to teh spec. You
> can't.

You need to improve your knowledge of Unix systems... ;-)

>>> Go back to playing with Windows, and stop posting to this newsgroup,
>>> since you obviously have little to contribute anyway. And VMS and DEC
>>> bashing in general is not classified as "contributing".
>
> Interesting that VMS bashing is not allowed, but UNIX bashing is (by some
> people's rules, anyway). Free speech?

Last I looked, this was comp.os.vms. Feel free to bash VMS all you want 
on comp.os.unix. :-)

>> Dammit! I need some VMS hardware...I hate UNIX and I have no freedom of
>> choice...
>
> You have...lots of UNIX-spec systems out there.

All of them behaving the same way, yes...

I know way more Unix that I'd ever want to. I've hacked the innards of 
the BSD4.3 Reno kernel, lots of NetBSD whacking, and lots of Linux 
whacking. All in the kernel. And I cannot count how much stuff I've done 
at the user level of different Unix systems.

Oh, and I have even less clue about how much I've hacked the 2BSD kernel 
and userland. After all, if it is a PDP-11, it can't be all bad. :-) But 
2BSD don't have NFS.

	Johnny