[Info-vax] Uptime for OpenVMS

[Johnny Billquist]

On 2011-05-11 18.06, Bill Gunshannon wrote:
> In article<iqf63n$57t$1 at iltempo.update.uu.se>,
> 	Johnny Billquist<bqt at softjar.se>  writes:
>> On 2011-05-11 13.12, Bill Gunshannon wrote:
>>> In article<iqema8$ltc$1 at dont-email.me>,
>>> 	glen herrmannsfeldt<gah at ugcs.caltech.edu>   writes:
>>>> Bill Gunshannon<billg999 at cs.uofs.edu>   wrote:
>>>>
>>>> (snip, I wrote)
>>>>>> For most, the disk has to keep running throughout.  For a diskless
>>>>>> client off an NFS server, even that isn't needed.  (Diskless NFS
>>>>>> clients survive a server reboot.)
>>>>
>>>>> Well, if you were considering possible disk failure, how about I build
>>>>> a system with just a ramdisk?  :-)  No moving parts beyond electrons.
>>>>
>>>>> And talk about being old. Unless they have fixed it (which I
>>>>> doubt as I never saw anyone in the linux crowd admit it was done
>>>>> wrong) Linux versions of NFS are, in some way, stateful and a reboot
>>>>> of the server requires a reboot of all the clients.  One of the
>>>>> reasons I have resisted moving anything here to Linux as we rely
>>>>> very heavily on NFS and I can't be rebooting all our clients if I
>>>>> have to take the fileserver down for any reason.
>>>>
>>>> Yes, all my diskless NFS work was with Sun hosts.  I had many
>>>> survive a server reboot.  Then once we sold a server, while the
>>>> clients sat there waiting for it to come back...
>>>>
>>>> Stateless (except for file lock) is supposed to be part of NFS.
>>>
>>> True.  And yet, people still wonder why I think Linux is pure crap.
>>
>> Linux is crap. That's old news. :-)
>> But it's moving crap, which in some ways is better than things sitting
>> still sometimes.
>>
>> However, as for NFS statelessness, it's not totally true.
>> For an NFS client to be able to continue operating after the server have
>> rebooted, the server must not have changed its hardware configuration,
>> or else the device handles that the NFS client holds becomes invalid.
>
> That can't be exactly true.  With systems other than Linux I have
> taken down one piece of hardware and brought up another totally
> different piece of hardware and as long as the new system presented
> the same exported file systems as the previous one the clients would
> pick it up and march on.  With Linux, iunless I actually umount
> everything NFS beforehand. all I have to do is reboot the server and
> all is lost.  The clients can not umount the partitions because the
> server knows they are no longer mounted and istead of just saying
> "OK" to the umount command it will NAK all the reuests leaving the
> client still holding a mountpoint it can not clear. Thus, a reboot
> of the client is necessary.
>
> Nothing other than Linux has ever exhipited this behavior.

I have had SUN machines (in the old days of SunOS 4.1) fail to access 
NFS on the server after a server reboot. But it only happens if you had 
added or removed a disk. Even if it isn't the one you were accessing, 
and the disk could be accessed just fine locally after reboot.
So there is some kind of device identifier held by the client, which can 
be changed after a reboot, if the hardware changes, that will cause NFS 
to fail. I have not looked at the NFS protocol in detail to tell exactly 
how it works, but I have seen server reboots that clients survive just 
fine, and I have seen ones where the clients didn't. But since server 
changes aren't that often, I'd say that around 99 times out of 100, the 
client survives a server reboot just fine.

 From the sound of it, it would appear that for Linux, things are much 
worse.

	Johnny