2012/6/1 Goswin von Brederlow wrote: > That should be: > mount /tmp to tmpfs only when amount of free space in /tmp is fewer > than the tmpfs would have or when /tmp is currently read-only.
Yes, of course. IIRC current script already checks for read-only root. So this check don't have to be added. >> Looks reasonable? Will that suit everyone? > > No. :'-( > If /tmp is already mounted as a seperate partition then tmpfs should > not be mounted. Hm... Good point. Debian should not try to be smarter than admin. If admin specified a mountpoint for /tmp then it must be used whatever size it is. > It might be neccessary to mount a tmpfs if the remaining > size in /tmp is less than TMP_OVERFLOW_LIMIT. This case would only occur > if the seperate /tmp filesystem is broken in that it can't be cleaned. Yes, I guess so. > With people doing stupid things like using just one partition you easily > have 3TB free in / and therefore /tmp. Actualy having less space in /tmp > than tmpfs would get would be quite rare. This idea comes from an attempt to make everything work for small root partitions without breaking things that were working before. > So tmpfs would basically never be used despite the benefits. Well, nobody named the benefits yet. Just the problems. There were a few attempts with some artificial test scripts, but no examples of real applications becoming faster with /tmp on tmpfs. And it's kind of pointless to change the defaults just to make some useless scripts faster. I could try finding a better solution if I knew the benefits. > Or maybe I just like tmpfs and have configured my system to set the > right options in /etc/default/tmpfs. You are completly ignoring that > configuration. Or course, if you set the option it must be used. I was not suggesting to force that, just add one more option. For example in addition to RAMTMP=yes and RAMTMP=no add value RAMTMP=auto, and make it default value. So if you set RAMTMP=yes you'll get tmpfs (whatever you set in fstab). But if you don't set it you'll get "auto" behavior. > In general your option assumes that you need the maximum amount of free > space in /tmp. That is simply not true. It should solve all the "tmpfs" problems listed in the thread and break nothing. That was the goal. > In most cases a small /tmp is just peachy. In *some* cases I would say. But I see nothing good in a small /tmp for default debian users. :) > Because of this it is hard to set a minimum size where > tmpfs would be too small to be usefull. For some user that would be > 100MB, for others it is 100GB. I assume that it's still possible to change default options. I.e. you're free to change RAMTMP and TMP_SIZE to your needs. > Best I can come up with is that applications that need lots of space in > /tmp, which are few, could check in postinst and give a debconf notice > that /tmp should be resized One of those "few" applications is "tar", used by mc. I can't suggest a proper tmpfs size for it. ;) > Your option would make all my systems unbootable since / is read-only, > includes /usr and has some GB free space. I considered that. I was just trying to keep description shorter and easier to understand. A more complete description would look like: 0. fstab is already processed and /tmp was (or was not) mounted to a separate partition. 1. init-script cleans it (since it must clean it anyway) 2. and checks `df /tmp/` for free space and partition 3.a. if RAMTMP == yes or RAMTMP == no then goto 4 3.b. if RAMTMP != auto then print a warning 3.c. if /tmp is not writable then RAMTMP=yes; goto 4 3.d. if /tmp is not on a root partition then RAMTMP=no; goto 4 3.e. if has_less_than_TMP_SIZE_free_space then RAMTMP=yes; goto 4 3.f. else RAMTMP == no 4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space then RAMTMP=yes 5. if RAMTMP == yes then mount /tmp to tmpfs Maintainer will probably write a better code. PS: Have you thought about mount-binding /tmp to /home/tmp for your read-only root systems? Or your /home partition isn't local? -- Serge -- 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/CAOVenEpy-zwzyKB7MYsGb=xCB6sBPAKD6uyDDVRF9GnrZ1=o...@mail.gmail.com
