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

[LDM #WDB-706909]: Restarting LDM

Hi Martha,

re:
> I am sorry I am late answering; I was out of the office for several
> days.

No worries.

> I have placed a "close" directive for each of the types of data we are
> collecting from our NOAAPORT ingestor, but have not edited the thredds
> Pqact file that collects data from CONDUIT.

OK.

> I am attaching a list of
> files shown open but deleted, and I believe they are all CONDUIT files.

Yes, they also appear to me to be files from CONDUIT.

> It may be something we have to live with, if we must use 'flush' rather
> Than close, at least until our network situation improves re the
> CONDUIT.

The question remains why you need to scour these files as frequently
as you now doing?  I was under the impression that the problem you
were originally trying to solve was one of there being too many
BUFR files in a directory being populated by McIDAS-XCD GRIB/BUFR
processing.  Those files are _not_ held open, and can be deleted
as often as you like.  Since there is no BUFR ADDE server in the
current McIDAS distribution, you can quickly delete the BUFR files
without worrying about making sure the MySQL database that is keeping
track of GRIB metadata is in sync with your deletions.  If the
problem is the number of GRIB files being saved by the McIDAS-XCD
GRIB/BUFR processing, then you _do_ have to worry about keeping
the MySQL database in sync with the disk file deletion.

> As to whether we are running out of disk space, I think it is more me
> being proactive.  We did have one instance when we did fill our disk,
> But that was before I had realized there was an issue with BUFR files
> and "too many files" for the rm command.  So no, we are not in a critical
> mode regarding disk space; it's just be trying to figure out what
> Was going on, when a "du -sk /data" did not equal "df  /data" and I
> realized there were phantom files.

I would choose the path of least resistance and not worry so much
about scouring files that likely do not need to be scoured as
frequently.  Instead, concentrate on the BUFR files from CONDUIT that
are being written to disk as part of the McIDAS-XCD processing.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: WDB-706909
Department: Support LDM
Priority: Normal
Status: Closed