[ SDF Public Access UNIX System .. Est. 1987 ]

join welcome faq status members projects store tour gopher abuse dialup minecraft social
tilde nihongo europa webmail gallery usermap irc tutorials telnet git ssh


     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:

     load: 2.04  cmd: tail 12966 [select] 0.00u 0.00s 0% 808k

     [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.


©1987-2065 SDF Public Access UNIX System, Inc. 501(c)(7)
(this page was generated using ksh, sed and awk)