On Sun, Mar 25, 2012 at 10:51:07AM +0000, Camaleón wrote: > On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote: > > On Sat, Mar 24, 2012 at 11:10 AM, Camaleón <noela...@gmail.com> wrote: > >>>> You may also consider filing a bug, since the more people report > >>>> problems with Debian's new, absurdly small /tmp, the more likely it > >>>> is to get fixed. > >> +5 > >>> Why? > >> Because the default is giving some headaches to the users? > > How many? Or how many would you consider critical mass to make things > > change? > > To me it's just not possible to provide defaults satisfying all users. > > Of course. > > But when something that was working stops doing it my auto-defense system > sends me a warn (beep, beep!) and I have to find what have caused the > problem. When a default setting is causing the problem then the default > is not good for me. When other users complain for the same issue, then > the default is neither good for they and it can be a signal for that > default is reviewed and commented with other community of users to get > more feedback.
As the person who created these defaults, just a few points for everyone in this thread to consider: The existing defaults are not intended to be universally usable. They are intended to work on every system to provide a certain base level of functionality. That being said, improvements are always welcome. The defaults are intended to work on even systems without swap, so are intentionally small: /run RUN_SIZE 10% /run/lock LOCK_SIZE 5MiB /run/shm SHM_SIZE[=TMPFS_SIZE] 20% /tmp TMP_SIZE[=TMPFS_SIZE] 20% -------- 50%+5MiB -------- The intention here is that if every tmpfs is filled, you only commit 50% of core memory. Of course, if you have lots of swap space, you can increase these limits massively. Or you can disable the use of tmpfs (except for /run) and use normal filesystems. The run and lock sizes are I think appropriate for all but the most extreme uses. shm and tmp are very dependent upon specific application use, and choosing sensible defaults here is hard. Regarding altering of the size limits: currently hardcoded in /lib/init/tmpfs.sh. We could compute these dynamically if we know at the time how much swap is additionally available. Or have different profiles depending upon expected usage. Regarding the use of /tmp on tmpfs being the default. I still think that tmpfs makes sense for /tmp. It is certainly appropriate for many users. We can certainly improve the defaults if we understand what problems users are having. But they need to be reported. 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. - /var/tmp exists, and should be used in many of the cases where /tmp is being filled. 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? What is the minimum space an individual user or application should be able to use? Should certain applications be patched not to use /tmp for storing "excessively large" files? etc. These are obviously not questions with straightforward answers. But I hope they do help to provide some understanding as to why simply not using tmpfs on /tmp is not necessarily the "right" or best long-term strategy. This definitely needs more thought, but it also needs a greater understanding of what users and applications expect /tmp to provide. Investigating what other init systems and distributions do might be instructive here. When we introduced these defaults, we wanted to make them configurable directly in the installer, by making tmpfs mounts editable in the partitioner (or removed entirely). I'd still like to do this, but it needs someone with the time to add tmpfs filesystem support to d-i. I took a look a few months back, but lacked the time or d-i expertise to do this. [There are prior discussions of this on -devel, which probably include more detail and other things I unintentionally omitted.] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120327131323.gc30...@codelibre.net