Counting files created in /tmp

Jonathan I. Kamens jik at athena.mit.edu
Fri Feb 2 15:35:01 AEST 1990


In article <22031 at unix.cis.pitt.edu>, yahoo at unix.cis.pitt.edu (Kenneth L Moore)
writes:
> So the answer to his question about a SIMPLE way to keep track of what 
> has happened in temp, assuming he knows when he wants to look at it,
> is:
> 
> ls -la /tmp

  The person who asked the original question is trying to collect some
really meaningful statistics about file names, sizes and lifetimes in
the /tmp directory.

  As I think I've already pointed out, file lifetimes in the /tmp
directory have a very wide range.  A periodic ls of /tmp simply doesn't
have a chance of catching many of them, although I guess you could just
run it continually, over and over, and even that wouldn't catch all of them.

  Worse, if an execution of the program "ls" is used to get the data,
then the extra overhead of:

  1. Starting up an ls process.
  2. Ls time to get the whole directory.
  3. Ls time to format its output.
  4. Kernel time to give you the output to work with.
  5. If you do it with a pipe, kernel time to context switch between 
     the processes on both sides of the pipe.

make the program significantly run faster.

  It is relatively simple to write a program to do a periodic opendir()
and readdir() on /tmp itself.  This will significantly speed up the
program and make it far more able to collect meaningful statistics.

  There are times when modularity and chaining different unix utilities
together in a pipe are good.  This is not true, however, when speed is
an important factor.

  As an example, I just wrote a shell script that takes a number as an
argument and does "ls /tmp/ | wc -l" that many times.  I then wrote a C
program that does the same thing, but it does the counting internally,
not using ls.

  Doing the count twenty times, the shell script took 20.4 seconds on a
very lightly loaded system.  Doing the same thing with the C program
toom 0.3 seconds.

  It took me less than five minutes to write the C program, and it would
take me a minimal amount of time to augment it to collect more statistics.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710



More information about the Comp.unix.questions mailing list