Wouter Verhelst <wou...@debian.org> writes: > On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote: >> 2012/6/1 Goswin von Brederlow wrote: >> > So tmpfs would basically never be used despite the benefits. >> >> Well, nobody named the benefits yet. > > - You could mount your mail spool there, and make things go blazingly > fast [1]
Some month ago there was a /. article (sorry, don't have a link) about a mail service achieving 99% compression on mail spools and being balzingly fast speading mails like crazy. And yes, they keep all mails in ram. Any disk access would just slow down spreading the mails around. 8-) > - It speeds things up, especially on systems with loads of RAM and no > swapspace: whenever there's a possibility of disk access, no matter > how remote, you risk slowing things down due to that disk access. > Reducing disk access for things that don't need to be stored forever > is *good*. On that note it also keeps the disk free to read/write other stuff. Like the next input file or storing the final output file. On a cold cache that can make a difference. > - anything which reduces the number of possible disk accesses is good > for people using SSDs (I have a laptop with SSD, and no swap, and love > tmpfs for precisely that reason). > - In the (on laptops and desktops) fairly common > "one-partition-for-everything" set-up, there's no risk of a runaway > process eating up your diskspace with huge files in /tmp and therefore > making it impossible for syslogd to write anything to disk anymore so > you can figure out what the f*** happened > - It makes for an interesting "I need to compile something quickly just > to test something out" area, where it doesn't matter if you forget to > clean up after the fact (yes, this is a bit of an abuse of /tmp; never > the less, I find myself doing such things in /tmp fairly often now > that /tmp is a tmpfs) Me too. > - it's called *tmp*fs for a reason (no, that's not a benefit. Yes, > that's an argument in favour) > - There's no danger of a symlink attack or similar with things like > tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the > system, and /tmp is clean again, no matter what was there before. This > is more than just a convenience. - No time wasted at boot to clean up /tmp. No journal replay, no fsck. > [1] As demonstrated on FreeBSD in > > <http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20041101/msg00145.html>. > No, I'm not being serious. MfG Goswin -- 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/87obono9m0.fsf@frosties.localnet
