Henrique de Moraes Holschuh dixit: >On Fri, 25 May 2012, Thomas Goirand wrote: >> for small files, and in that case, it's faster. In reality, it's >> not that much faster, thanks to Linux caching of the filesystem, > >Under heavy filesystem IO load, yes it is. By several orders of magnitude.
Not just that. It’s faster because the files don’t even get written to disc if they’re kept for, say, five minutes, and aren’t just short-lived. If you’ve got a slow hard disc (say low-end spec or old system), RAM’s still cheaper for tmpfs: no matter whether tmpfs or a real on-disc filesystem, buffer cache would still get it, AND the writes would be very slow (especially for short-lived files, _if_ the system is otherwise busy and would not wait before writing them to disc), and the system could concentrate on getting the files we want to disc instead of the temporary ones. And then there’s the CF card usecase. Or SSD, nowadays, I guess (my IBM X40 just got two CF cards to replace the HDD). There, you’d absolutely want to minimise disc writes. And just the chance that it could not end up there (except as part of swap) is better then the chance it could end up there (plus journal writes). >In fact it is the other way. We have /var/tmp for the large file since >about forever, and important platforms that have /tmp in memory since the >early 2000's (Solaris).... Right. /tmp always had size limitations, it used to be no bigger than a few MiB, and people were ALWAYS tought to use /var/tmp for files that are large, should not be removed across reboots or from a cronjob pruning /tmp files older than 7 days, or a combination of these. (Uglities like /usr/tmp notwithstanding, although I’ve mostly seen that as compat symlink to /var/tmp later.) I’m absolutely for /tmp as tmpfs by default. Even, no, especially on low-end systems. Heck, be lucky it’s tmpfs and not Classical BSDs’ mfs (basically a variable-size 4.2FFS ramdisc, not just an object store in the buffer cache). Every tool either supports setting TMPDIR=/var/tmp before running it or is buggy. Go fix these instead, and then just run them with that if you need them to process files you don’t want in tmpfs. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205251057460.4...@herc.mirbsd.org