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

20000926: McIDAS: /data/ldm/mcidas directory

>From: Mike Keables <address@hidden>
>Organization: DU
>Keywords: 200009262240.e8QMeRb16614 McIDAS-XCD scouring


>I'm having a problem with /data/ldm/mcidas filling up about every three days
>or so.

This sounds like data scouring is not working for some reason.

>Has the McIDAS product queue grown in size substantially?

No, not really.

>Here is what I have for disk allocation on cyclone:
>> df -k
>Filesystem            kbytes    used   avail capacity  Mounted on
>/proc                      0       0       0     0%    /proc
>/dev/dsk/c0t0d0s0      96455   44827   41983    52%    /
>/dev/dsk/c0t0d0s6     877790  595877  220468    73%    /usr
>fd                         0       0       0     0%    /dev/fd
>/dev/dsk/c0t0d0s1     413639   70258  302018    19%    /var
>/dev/dsk/c0t1d0s7    8509324 6958112 1466119    83%    /data
>/dev/dsk/c0t0d0s7    4031022  596346 3394366    15%    /export/home
>/dev/dsk/c0t0d0s5    3007086 1085842 1861103    37%    /opt
>swap                  624208     376  623832     1%    /tmp

At this point, there /data has 1.4 GB of space available.

>Is there a way to control the amount of data stored on /data or is a sc
>running properly?

It is as though scour is not running properly.  I seem to remember that
you ran into something like this in the past also.  Am I remembering

>It seems that I get GRID files on the order of 2-3 days old (or 
>more sometimes) and my current solution is to delete the older files.

This really does say that scouring is not working.


Here is what I did:

<login as 'ldm'>
cp ~mcidas/workdata/mcscour.sh decoders
<edit .cshrc and add a clause to the definition of 'path' so that mcscour.sh
will work correctly from the ldm account>
<edit crontab and change the invocation of mcscour.sh from
/export/home/mcidas/workdata/mcscour.sh to decoders/mcscour.sh>

cd decoders

So, mcscour.sh runs fine "by hand".

Since this scouring is logged to ~mcidas/workdata/scour.log, it would
be useful if you would keep an eye on this file to see if cron is
failing to kick it off occasionally (the time stamp on the file
tells us when scouring was run).  If it is failing to run, then there is
some sort of a problem with cron on your system (but I don't know what).
If it is running, and the files are not being deleted, then there is
some other problem which we will need to get to the bottom of.  If/when
you see that scour hasn't run, please let us know immediately.  This way
we may be able to see what the cause is.

One other thing you could try is running the scouring more than once
per day.

>Thanks in advance,
>--Mike Keables


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.