[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030707: LDM-6 upgrade at McGill (cont.)
- Subject: 20030707: LDM-6 upgrade at McGill (cont.)
- Date: Tue, 08 Jul 2003 08:58:41 -0600
>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