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

20031007: disk space blues (cont.)



>From: "Klein, William" <address@hidden>
>Organization: Valparaiso
>Keywords: 200310061909.h96J98k1027137 McIDAS-XCD mcscour

Bill,

>I believe we are only gathering GEMPAK data (haven't hub'ed in the new
>pqact.conf yet) and McIDAS.

Got it.

I found that the disk space was being used by NEXRAD Level III products
which weren't getting scoured correctly.  After doing some cleanup,
/var/data now has 25 GB of space.

The real culprit appeared to be a misspecification of PATH in
~ldm/util/prune_nexrad.csh: /home/ldm/decoders was being added to the
PATH, but it should have been /home/ldm/util.  I corrected this problem
and scoured the various ~ldm/data/nexrad/NIDS subdirectories "by hand"
to get things going again.   I also removed the /var/data/mcidas
directory since it was archaic (data was very old and not being
updated), and removed very old files in /var/data/ldm/mcidas (which
were remenants of improper scouring).

I think data decoding should now work correctly, but there is a
possibility that some McIDAS datafiles were damaged when the disk ran
out of space.  This will have to be monitored by someone at Valparaiso
(by running McIDAS routines that access the POINT data (sfc, upper air,
etc.)).  Please let me know if problems are found.

Also, we got an email from Wenxian Lu <address@hidden> regarding
a problem decoding data into GEMPAK format.  I sent him a note telling
him that the problem was most likely (for sure) due to /var/data
being full.  He will have to keep an eye on the GEMPAK decoding
to let us know if does not start working again.

Cheers,

Tom


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.