Re: Idea: mount /tmp to tmpfs depending on free space and RAM
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
Reply to: