[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030707: LDM-6 upgrade at McGill (cont.)

>From: Tom Yoksas <address@hidden>
>Organization: UCAR/Unidata
>Keywords:  200307071420.h67EKGLd015022 LDM-6 setup request

Hi Alan,

After looking at the latencies on maelstrom2 overnight, I decided that
any data arriving from dragon.geog.ubc.ca was very old and had most
likely already been received from atm.geo.nsf.gov.

Given this, I decided that it was prudent to turn off the feed from
dragon, but I was unable to edit the ~ldm/etc/ldmd.conf file because
there was no disk space left in /tmp.  Even though /tmp is not on the
same disk as the ~ldm/data, I decided it was prudent to delete some old
data files in ~ldm/data/upperair, ~ldm/data/surface/boy,sao,syn.  It
would be a good move to setup scouring of the data directories in the
'ldm' account unless you have this setup in some other account and I am
just not seeing it.

In order to free up some space in /tmp, I briefly looked around in '/'
to see what was taking up room.  I found a very old distribution of
GEMPAK (from back in June of 2000):

-rw-r--r--    1 root     sys      114361247 Jun 26  2000 gempak54upc_pl16.tar.Z

I took the liberty of moving this file to ~ldm/data/archaic.  I
recommend that this file be deleted since the 5.4 version of GEMPAK is
no longer supported.  After moving the old GEMPAK distribution file,
there was enough room in /tmp to allow me to edit ~ldm/etc/ldmd.conf.

However, I watched disk space use for awhile, and I saw the space on /
being used at a pretty rapid pace.  I stopped the LDM and continued to
monitor the usage of / and saw that it continued to go down at the same
pace, so the LDM is not the cause of the disk usage.  As I finish writing
this note, the space freed by moving the old GEMPAK distribution
file has been entirely used up:

maelstrom2 34% df -k
Filesystem             Type  kbytes     use     avail  %use Mounted on
/dev/root               xfs  4269500  4236384    33116 100  /
/dev/dsk/dks0d2s7       xfs 71665568 63157376  8508192  89  /diskA

This situation needs to be looked into.

In the meantime, I turned off the running of pqbinstats from
~ldm/etc/ldmd.conf and stopped trying to send the results back to
Unidata by email.

Tom