David LeBauer's questions

I am developing a program that runs on a cluster and writes a lot of short bits. First, it outputs to the node's scratch directory; when it is done, it rsyncs the files to a hard drive and then removes them from scratch. Without this step, the program often gets stuck. I am on a RedHat cluster with Rocks.

The program isn't perfect, and during development, many users may leave orphaned unneeded files on scratch (they have already been rsync'd).

For my own files, I use this script to get rid of the orphaned files:

for i in {1..24}
do
ssh compute-0-$i "rm -rf /scratch/*`
done

However, I have the following questions:

1. does this violate any "best practice" rules?
2. to delete all files from all users whenever anyone runs it, must I chmod -R a+rw /scratch?

I share a server with HAL. The server has 32 GB of memory.

I rarely use more than 1 GB of memory, and when I do, it is for a few minutes at a time, and I don't mind sending such jobs to the back of the line.

HAL read/writes large files (e.g. using gunzip). This can take up to 100% of the memory CPU, intermittently, for hours. This is usually done overnight, but when running, will make even simple commands such as cd take 30s, opening emacs can take minutes.

I would like to be able to reserve 1 GB for use by processes that use << 1GB (like a text editor). I would also like to stay out of HAL's way, and see no reason that this should be an issue.

HAL says that a queueing system (like PBS) can not be used to put a low priority on read/write, e.g. to leave 1 GB of memory always available when large jobs are running. In his words:

the script used to gunzip snags all the processors it can because the data is large... queueing would not solve this... during transfer of files from (that server) to (this server), an inflation step does lots of read/write

Why couldn't queuing solve this problem? What could?