home *** CD-ROM | disk | FTP | other *** search
/ norge.freeshell.org (192.94.73.8) / 192.94.73.8.tar / 192.94.73.8 / pub / sdf / faq / MISC / 09 < prev    next >
Text File  |  2004-04-08  |  3KB  |  54 lines
  1. [09] WHAT SHOULD I DO IF A SYSTEM CRASHES OR LOCKS UP?
  2.  
  3.      Hopefully this will not happen at all to you, but if you experience
  4.      'lock ups' or 'freezes', please follow these steps to help prevent
  5.      your own data loss.
  6.  
  7.      Also, it is important to note that you do not have a direct connection
  8.      to SDF and are mostly likely hopping through 10 or more networks to
  9.      get to SDF.  You can use ping and traceroute to measure lag between
  10.      your computer and SDF.  So, your experience of lag on SDF is subjective
  11.      and it is very important for you to understand that.
  12.  
  13.      Typically a lockup will occur when you are trying to access a 
  14.      file that is resident on the fileserver.  For instance, say you
  15.      are trying to cat a file and instead of seeing the contents you
  16.      get either nothing or a message similar to:
  17.  
  18.      ol1:/sys: not responding
  19.  
  20.      Be patient, the fileserver will recover shortly and your task
  21.      will be completed .. you will probably see:
  22.  
  23.      ol1:/sys: is alive again
  24.  
  25.      which means your request will actually begin to be processed.
  26.  
  27.      During the hang time, you can use ^T (CTRL T) to display the
  28.      status of your job .. for instance:
  29.  
  30.      load: 2.04  cmd: tail 12966 [select] 0.00u 0.00s 0% 808k
  31.  
  32.      [select] is the current state of the process id 12966 which
  33.      is the 'tail' program.  If the system is waiting on actual
  34.      disk I/O, you'll probably see [biowait].  In cases of a hang
  35.      you may see either [nfsrcvlk] (Network File System Received Lock)
  36.      or [vnlock] (Virtual Node Lock) which the system will usually
  37.      recover from, but can be telling of a serious resource problem
  38.      on the NFS client should this state be prolonged.
  39.      
  40.      In the event that the fileserver becomes unavailable, it is 
  41.      important that you do not become impatient and interrupt, quit 
  42.      or suspend your jobs (^C, ^\ or ^Z) but rather, wait them out.
  43.      If you are patient your chances of losing data will be
  44.      significantly reduced.  Usually the fileserver will respond
  45.      within a few seconds, but usually no longer.  In the case when
  46.      it is the NFS client's problem (vnlock for more than say 20
  47.      seconds) that particular host will most likely need to be reset.
  48.  
  49.      More on this.  SDF is pushing NetBSD to its limits and we are
  50.      currently (2003-2004) doing quite a bit of investigation with
  51.      the uvm/vfs/vnode code developers to help NetBSD become scalable
  52.      in high usage situations such as the loads we experience on SDF.
  53.      Solutions we find will be incorporated into the public code.
  54.