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

20031007: disk space blues (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20031007: disk space blues (cont.)
  • Date: Tue, 07 Oct 2003 12:59:23 -0600
>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