[09] WHAT SHOULD I DO IF A SYSTEM CRASHES OR LOCKS UP?
Hopefully this will not happen at all to you, but if you experience
'lock ups' or 'freezes', please follow these steps to help prevent
your own data loss.
Also, it is important to note that you do not have a direct connection
to SDF and are mostly likely hopping through 10 or more networks to
get to SDF. You can use ping and traceroute to measure lag between
your computer and SDF. So, your experience of lag on SDF is subjective
and it is very important for you to understand that.
Typically a lockup will occur when you are trying to access a
file that is resident on the fileserver. For instance, say you
are trying to cat a file and instead of seeing the contents you
get either nothing or a message similar to:
ol1:/sys: not responding
Be patient, the fileserver will recover shortly and your task
will be completed .. you will probably see:
ol1:/sys: is alive again
which means your request will actually begin to be processed.
During the hang time, you can use ^T (CTRL T) to display the
status of your job .. for instance:
[select] is the current state of the process id 12966 which
is the 'tail' program. If the system is waiting on actual
disk I/O, you'll probably see [biowait]. In cases of a hang
you may see either [nfsrcvlk] (Network File System Received Lock)
or [vnlock] (Virtual Node Lock) which the system will usually
recover from, but can be telling of a serious resource problem
on the NFS client should this state be prolonged.
In the event that the fileserver becomes unavailable, it is
important that you do not become impatient and interrupt, quit
or suspend your jobs (^C, ^\ or ^Z) but rather, wait them out.
If you are patient your chances of losing data will be
significantly reduced. Usually the fileserver will respond
within a few seconds, but usually no longer. In the case when
it is the NFS client's problem (vnlock for more than say 20
seconds) that particular host will most likely need to be reset.
More on this. SDF is pushing NetBSD to its limits and we are
currently (2003-2004) doing quite a bit of investigation with
the uvm/vfs/vnode code developers to help NetBSD become scalable
in high usage situations such as the loads we experience on SDF.
Solutions we find will be incorporated into the public code.
