Messages in this thread |  | | | From | (Larry McVoy) | | Subject | Re: /tmp in swap space | | Date | 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
|  |