>From: Mike Keables <address@hidden> >Organization: DU >Keywords: 200009262240.e8QMeRb16614 McIDAS-XCD scouring Mike, >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 correctly? >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. >Suggestions? 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 ./mcscour.sh 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 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.