Re: /tmp in swap space

Larry McVoy (lmcvoy@dnai.com)
Sat, 23 May 1998 00:37:46 -0600


: I recently saw that Solaris shares the drive space for swap and for the
: files in the /tmp directory (/tmp is mounted from the swap partition as
: filesystem type swapfs).
:
: Has anybody thought about this? Has this already been done for linux in
: some patch somewhere? Are there solid reasons not to do this? would a
: significant performance impact be unavoidable? Would it be difficult to
: use the ulimit settings for quota on the '/tmp-filesystem'?

The last time I looked at this closely was when I was writing lmbench,
in particular, the file system latency tests. TMPFS was a win over
UFS because small, short lived files are expensive to create in UFS -
the file system does a sync write to the disk to update the meta data.
The sync write limited file creates to about 35/sec (single threaded),
whereas TMPFS got ~1000/second.

EXT2FS doesn't do sync writes for file creates so the advantage of
TMPFS is greatly reduced.

Here's my old data, which is somewhat dated, but interesting none the
less. It should convince you that ext2fs is fast enough; if it doesn't,
please send me some mail and let's discuss it before you spend a lot of
time working on the problem, I don't think there is much gain to be had.
And I probably have much more up to date data. In fact, Linus sent me
400Mhz Pentium II numbers just today. Yes, things have improved a bit:
Linux can now do 52,631 creates/second. And 500,000 deletes/second.

On the other hand, TMPFS is somewhat useful for large file I/O, it will
run at bcopy speeds. I'm hardpressed to think of a case where having
high bandwidth for short lived files is a win - most of the files created
in /tmp are temp files, and are usually a few KB to a few MB. For files
that small, higher bamdwidth isn't going to gain you anything (and EXT2FS
will approximate TMPFS for smaller files which fit in the cache).

--lm

$Id: Results,v 1.1 1994/11/16 22:08:53 lm Exp lm $

sunray 4/470 33Mhz SunOS 4.1.3
bucket 150mhz IP19 MP IRIX 5.3 alpha (debugging on, logical volumes on)
indy 100Mhz IP22 IRIX 5.3 alpha (debugging status unknown)
rios 62mhz rs6000 AIX 2.3 (fast & expensive machine)
alpha 250(?)mhz alpha OSF/1 V2.1 (I think this machine has NVRAM)
snake 100mhz HP snake HP-UX

create delete
Host FS Size N /sec /sec
----------------------------------------------
sunray TMPFS 0k 500 1206 6021
sunray TMPFS 1k 500 735 3400
sunray TMPFS 4k 500 680 3061
sunray TMPFS 10k 500 455 3106
sunray NVRAM 0k 500 156 394
sunray NVRAM 1k 500 149 216
sunray NVRAM 4k 500 141 146
sunray NVRAM 10k 500 121 210
sunray UFS 0k 500 34 90
sunray UFS 1k 500 35 22
sunray UFS 4k 500 36 23
sunray UFS 10k 500 35 31

create delete
Host FS Size N /sec /sec
----------------------------------------------
bucket XFS 0k 500 236 293
bucket XFS 1k 500 275 307
bucket XFS 4k 500 271 324
bucket XFS 10k 500 247 312
bucket EFS 0k 500 86 90
bucket EFS 1k 500 29 46
bucket EFS 4k 500 29 45
bucket EFS 10k 500 29 44

create delete
Host FS Size N /sec /sec
----------------------------------------------
indy EFS 0k 500 86 87
indy EFS 1k 500 45 33
indy EFS 4k 500 38 33
indy EFS 10k 500 32 32

create delete
Host FS Size N /sec /sec
----------------------------------------------
rios JFS 0k 500 79 79
rios JFS 1k 500 78 78
rios JFS 4k 500 78 79
rios JFS 10k 500 78 79

create delete
Host FS Size N /sec /sec
----------------------------------------------
alpha UFS 0k 500 898 2944
alpha UFS 1k 500 180 195
alpha UFS 4k 500 118 199
alpha UFS 10k 500 74 171

create delete
Host FS Size N /sec /sec
----------------------------------------------
snake HFS 0k 500 45 90
snake HFS 1k 500 30 45
snake HFS 4k 500 29 45
snake HFS 10k 500 22 45

create delete
Host FS Size N /sec /sec
----------------------------------------------
pentium EXT2FS 0k 500 626 5338
pentium EXT2FS 1k 500 526 4468
pentium EXT2FS 4k 500 354 3162
pentium EXT2FS 10k 500 170 239

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