Re: /tmp in swap space

Larry McVoy (lmcvoy@dnai.com)
Sat, 23 May 1998 15:57:28 -0600

: Larry McVoy wrote:
: > ... (and EXT2FS will approximate TMPFS for smaller files which fit in
: > the cache).
:
: If I do the following:
:
: open ("/tmp/file", O_CREAT|O_TRUNC|O_WR)
: write (....) /* Small enough to fit in cache. */
: close ()
: /* Do some work, file still stays in cache. */
: unlink ("/tmp/file")
:
: Is ext2 clever enough to avoid writing data blocks for the deleted file
: to the disk? This has always struck me as the reason why a Linux tmpfs
: would be useful.
:
: I could ask is ext2 clever enough to avoid writing _anything_ in this
: case, but I think that's clearly asking too much.

It is indeed clever enough to do exactly what you want, which is why
a TMPFS is pointless for Linux systems which already have ext2fs.
lat_fs.c in lmbench has a test which creates 1,000 files of size 10K,
then deletes them, then repeats. The time for a create is !! 32 usecs !!
and about !! 3 usecs !! for a delete on a 400Mhz Pentium II. Pretty darn
good if you ask me. A 233Mhz AMD K6 is more like 780 & 72 usecs for
create & delete.

At any rate, all of these numbers would be little or no faster on TMPFS.
Once you get the disk out of the equation, which both EXT2FS and TMPFS
do for small tmp files, then you are purely CPU bound and the only thing
that will show up is code paths and the code paths are unlikely to be
dramatically different.

Feel free to snarf up the lat_fs.c code and try it on a Sun.

--lm

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu