On 2012-03-27 14:13:23 +0100, Roger Leigh wrote: > A common (and very persuasive) argument for not mounting a tmpfs > on /tmp and instead using the root filesystem is that by default > we install with a single large root filesystem, and /tmp gets to > use all the free space there. This is certainly true, and is a > major reason why we should consider doing this. However, the > following points also need to be considered: > > - having /tmp on / means that / needs to be writable by default > - having "limitless" space on /tmp means it can be abused by > both users and applications. It can lead to breakage on > systems with a limited /tmp if applications make the > (incorrect) assumption that they can store whatever they like > there. It's more sensible to provide a minimum guarantee.
What do you mean by "abused"? If it is limitless, there should be no possible abuse. IMHO, to avoid breakage due to limited space and due to some user taking all the space, there should be some compromise, such as: for any memory storage system (RAM+swap, tmpfs, disk...), there should be some space normally not used, and reserved for root (and possibly special system users/groups[*]) in case the normal space gets filled. AFAIK, this is already the case for disk space. [*] or arbitrary users, who could have their own reserved space to be able to do minimal work when some other user took all the space (i.e. a common pool that has the precedence + quotas on extra pools, which would be much smaller). > - /var/tmp exists, and should be used in many of the cases where > /tmp is being filled. But what is applications do not know in advance what to use, given the fact that the RAM+swap is much more limited than disk space in practice? Should there be a new FS to transparently use tmpfs for small files and disk space (/var/tmp or similar) for large files, and being able to move files from tmpfs to disk space when a file increases (without changing the pathname)? > It's hard to get a clear picture of what generally useful defaults > should be when you only get feedback from a handful of users. > > What should the minimum space be for /tmp? I have scripts that build and test software, and rm -rf everything after the tests and/or "make install". So, I was using /tmp for that (because it is faster than normal disk space, and cleaned-up at boot time in case something is left over). For small software, it is OK, but for large ones, /tmp got full. Should I use /var/tmp, even though /tmp would be OK in most cases? IMHO, the best solution would be some "union" FS as suggested above. > What is the minimum space an individual user or application should > be able to use? IMHO, the default limit should be the full space minus some small space to avoid breakage. This is more flexible than strict quotas. > Should certain applications be patched not to use /tmp for > storing "excessively large" files? The problem is that /tmp would be OK for some users and not for other users, in particular if the applications don't know in advance the amount of data they will need to store temporarily. If the answer is "in doubt, do not use /tmp" (possibly affecting most applications), then this would probably mean that /tmp should not use tmpfs. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120403111738.gc8...@xvii.vinc17.org
