In <821513319-1295910389-cardhu_decombobulator_blackberry.rim.net-57593962- @bda029.bisx.prod.on.blackberry>, teddieeb@tmo.blackberry.net wrote: >Isn't messing with volatile /tmp somewhat a moot point, given that the >Linux memory manager manages virtual memory anyway? I mean, if /tmp is >heavily used by your system, it will be cached in memory anyway. With 4 >GB of RAM (as mentioned by kellyremo), you'll end with probably your >entire payload (and not just your /tmp) running from RAM. So what's to >be gained with a /tmp in RAM, really? Not waiting on writes to disk. Also freeing up disk I/O bandwidth for other uses. fsync() or fdatasync() on tmpfs is virtually a no-op. fsync() or fdatasync() on a fully-cachec ext2/3/4 filesystem can still take quite a while. >In addition, there is a >possibility that dedicating 2 GB of RAM to /tmp, you could end up >forcing your system to start swapping out. tmpfs doesn't reserve much (if any) memory. So, unless it is being actively used by files in the tmpfs, it can be used by other applications. >it would take an extremely >specific/border/particular user case to warrant moving /tmp to a RAM >disk. If the points you mentioned were salient at all, that might be the case. In practice, putting /tmp on a tmpfs almost always speeds up both desktops and servers. It can make sense not to use the default of 1/2 of RAM for /tmp, but since it isn't a hard reservation it doesn't matter much. I've been running on a 2GB tmpfs /tmp for years. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.