Just out of curiosity, how do you specify a file delete in an RFT transfer
file?  I suppose I could always submit a dummy GRAM job and use the cleanup
tags to get the same effect, but I'd like to be as efficient as possible I
guess.  Your other idea about the sysadmin type script is a good one, I
think.  In fact, since GLOBUS_SCRATCH_DIR can be set to a different value
for each different installed scheduler, might it make sense to modify the
appropriate scheduler provider to report this scratch dir information?  That
would keep things organized nicely in the central MDS store, I would think.

Thanks,
Adam

On Mon, Apr 7, 2008 at 2:42 PM, Charles Bacon <[EMAIL PROTECTED]> wrote:

> I'd be inclined to use standard sysadmin type scripts for the filesystem
> monitoring, using something like ganglia/nagios/bourne-shell-what-have-you.
>  You can interface shell scripts to the Index Service, so that would provide
> your information system publishing of the data.  RFT can be used to delete
> files, so you could use that for the removal.
>
> Charles
>
>
> On Apr 7, 2008, at 12:27 PM, Adam Bazinet wrote:
>
> > We have recently implemented a caching scheme that ends up storing job
> > input files in GLOBUS_SCRATCH_DIR (and these files are not subsequently
> > cleaned up when the job finishes, hence the term "cache" =)  This is all
> > working well, but the part that has not been implemented yet is some kind of
> > cache eviction scheme.  Leaving the criteria for when files should be
> > removed from the cache aside for the moment, my question is this: is there a
> > way using existing Globus mechanisms to monitor the size of
> > GLOBUS_SCRATCH_DIR (or to put it another way, the amount of free space on
> > the partition containing the scratch directory?)  And, if the partition is
> > close to filling up, is there a way to delete those files?  Just looking for
> > ideas & suggestions right now, thanks!
> >
> > Adam
> >
> >
>

Reply via email to