On Thu, Apr 14, 2011 at 02:13:57PM +0100, Philip Hands wrote: > On Thu, 14 Apr 2011 10:15:07 +0100, Roger Leigh <rleigh@codelibre.net> wrote: > > On Thu, Apr 14, 2011 at 10:44:08AM +0200, Bastien ROUCARIES wrote: > > > On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz <karl@kgoetz.id.au> wrote: > > > > On Wed, 13 Apr 2011 10:32:42 +0100 > > > > Roger Leigh <rleigh@codelibre.net> wrote: > > > > > > > >> On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote: > > > > > > > >> Following the discussion yesterday, I'd like to propose doing > > > >> something like the example below. It's possible to size a tmpfs > > > >> as a percentage of core memory, the default being -o size=50%. > > > >> Rather than setting an absolute value, we can size e.g. /run > > > >> as a percentage of total memory, which should scale with /run > > > >> usage better than a fixed value. > > > >> > > > >> Proposal: > > > > [...] > > > >> /run/shm: No default (use general tmpfs default of 20%) > > > >> /tmp: No default (use general tmpfs default of 20%) > > > > > > If it wasn't already clear, having /tmp as a tmpfs is a > > /configurable option/, and it is /not/ the default (except when > > root is read-only (ro) in fstab). [...] > In short, I'm wondering why we don't just say that the default be to > have a tmpfs /tmp, set to be about as big as we would have set it if it > was on disk, and backed by enough extra swap to ensure that we're no > more likely to run out of RAM, and allow people to switch it off if they > don't like it, probably via a debconf question that modifies the choices > that we make for partition and swap sizing during installs. I would personally be quite happy in making a tmpfs /tmp the default. I've used tmpfs /tmp on all my systems for many years, and never have any problems. Given that it would be quite controversial to introduce, I didn't do that in this patch, but doing this for new installs would be good. One factor to consider is that by default we don't currently make any guarantees about the size of /tmp. If it's not a separate filesystem, it's constrained by the size of the root filesystem, which might be quite small. So storing massive amounts of data there is really not a good plan unless you've taken steps to ensure there's enough free space there. In my case, I have 16 GiB of swap space and have an 8 GiB limit on my /tmp tmpfs. Other people might mount a large partition there. The general point I want to make is that if you want to store large amounts of data on /tmp, you need to take steps to do that; we don't support it by default. In consequence, supporting a tmpfs on /tmp by default shouldn't be particularly problematic, even if the size is small. If you want larger amounts of space then one can either increase the tmpfs size (and possibly add more swap), or disable the tmpfs mount and mount a separate partition there. > The only problem I can see might be that things that munch their way > through memory (earlier versions of iceweasel come to mind) will take > much longer to bump into limits if we have too much swap, and so will > cause machines to grind to a halt as they swap all the drivel they've > filled memory with. Not that having less swap made that much less > painful -- more recent versions of iceweasel seem rather better though, > so perhaps we should not pander to broken software in our choice of swap > size. We run into this issue with larger systems in general anyway--when you have many gigabytes of memory, a process leaking memory will take much longer to use up the available resources before being killed. There's not much we can realistically do about that (process resource limits can partially mitigate this). But in general, this is going to be an issue whether the /tmp filesystem is backed by a disc partition or by the VM. So long as you have a sensible limit on the size of the tmpfs, this isn't going to be more problematic than on a "real" filesystem in terms of I/O load and safety. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature