On 05/25/2012 11:08 AM, Serge wrote: > I wasn't able to watch a web presentation (from something like > vimeo/youtube), because there was not enough free space in /tmp for flash > player to download and show it. Also mc was not able to open archives >
On the server side, you can add that MySQL often uses /tmp, for example mysqldump does, and files there can be huge too. It can be extremely dangerous to have a server's /tmp getting full, and swap getting highly used (eg: potentially, your server could simply crash). There's something you didn't address in your exhaustive list of reasons why /tmp shouldn't be tmpfs. One of the argument that most tmpfs advocate have is that most of the time, /tmp is sued 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, the write-back, and all sorts of mechanisms that improve performances on disk-based filesystems. So I still wonder what's the point. Maybe we should add a /small-files-on-tmpfs (choose a better name, of course...) folder so that apps know what to do, that'd be a lot more graceful than just switching to whole /tmp to tmpfs without any app knowing about it. I also think that having /tmp using tmpfs by default is a *very* bad move, and I agree that you were right to bring this discussion again if this bad choice for the default partitioning didn't go away. I also agree that at the very least, there should be a clear option for this in the installer (with non-tmpfs by default, IMO, but if there's a high priority question, then it doesn't matter much...). Thomas -- 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/4fbf16a3.8090...@debian.org
