Le Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh a écrit : > > I haven't got anything particularly new to add to the discussion here. > But I would like to refer you to the previous discussion on the > topic. I am well aware that the default does not satisfy all use > cases, but that's simply not possible for this problem. The best we > can do is have a good default. That could be by improving the > tmpfs default sizes and behaviour (my preferred solution). It could > be by defaulting to not using a tmpfs. However, the majority of > software which finds the tmpfs too small has unreasonable expectations > of what can be expected to be available (by default).
Dear Roger, thanks for your patient work. As you explained, with latest versions of sysvinit (currently un experimetnal), 20% of the whole memory (RAM + swap) will be used for /tmp. This will give a couple of gigabytes in systems with 8 Gb RAM + 8 Gb swap, which may be borderline when working with big files. On my system at work, I often need to sort big files, and I think that even coreutil's sort program does not check in advance if there will be enough space in /tmp. I often lose some time for forgetting to set TMPDIR before running a command. How about doing the reverse and defind the amount of memory that /tmp will not use ? This limit could be in the range of what is necessary to avoid a GNOME session to be killed, and fall back to a percentage if the memory is lower than that treshold ? Thhe current system of using a percentage of the memory, reduces the impact to the recommendation of increasing the swap size. For the moment, if one wants to give 1 Gb more to /tmp, he would have to increase the swap by 5 Gb. Have a nice week-end. PS: I think that it would be great if people could reduce the speed at which they send messages. We are about to release a "diversity statement", but the way this list is used, only males fluent in English and with a strong opintion express themselves. PPS: With the advent of virtualisation and cloud computing, we will definitely benefit stopping the applications to use /tmp as if it were a directory with a large amount of space. One of the reasons I do not set TMPDIR by default in my environment is that I would lose the benefit of having cruft cleaned at reboot. What we are perhaps missign here is a couple of sound recommendations, plus some facilities such as a temporary directory ready for the user somewhere, which would function like /tmp does. Something like getting XDG_SESSION_TMPDIR for free after login, without having to think on how to implement it. -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120526003657.ga20...@falafel.plessy.net