Serge <sergem...@gmail.com> writes:
> 2012/5/28 Roger Leigh wrote:
>
>> The primary cause of problems is simply that the tmpfs /tmp isn't big
>> enough. [...] what guarantees are offered by the system in terms of
>> minimum and maximum available space on /tmp? [...] Consider the default:
>> /tmp is on the rootfs (which [...] may have lots of free space or very
>> little). [...] consider tmpfs mounted on /tmp: the size specifies the
>> total available space.
>
> Well, technically, we already guarantee that. The option TMP_OVERFLOW_LIMIT
> does. It mounts /tmp to tmpfs if there's too few free space there. But we
> can make it better.
>
> Idea:
> mount /tmp to tmpfs only when amount of free space in /tmp is fewer
> than amount of RAM.
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.
> Technical details:
> 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 then compares `df /tmp/` with amount of RAM available.
> 3. If amount of RAM is larger it mounts /tmp to tmpfs
> 4. otherwise leaves /tmp as it is.
>
> This way we can guarantee that there will be as much space in /tmp as
> possible but *at least* as much as the amount of RAM available.
>
> Looks reasonable? Will that suit everyone?
No.
If /tmp is already mounted as a seperate partition then tmpfs should not
be mounted. 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.
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. So tmpfs would basically never
be used despite the benefits.
Even non stupid setups can have lots of space in /. Specifically when
you have /usr on / instead of a seperate partition. Having a few GB free
there is quite reasonable. Still a tmpfs makes more sense.
Even worse / can be read-only and then you always need a tmpfs for /tmp
or a seperate partition.
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.
In general your option assumes that you need the maximum amount of free
space in /tmp. That is simply not true. In most cases a small /tmp is
just peachy. 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.
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 according to
/usr/share/doc/something/README.tmp-resize to at least xGiB.
> IMHO: this option should not break anything (and may even fix something)
> so it can be enabled by default. But it MUST be possible to disable it for
> those rare cases when admin intentionally left /tmp on a small partition.
Your option would make all my systems unbootable since / is read-only,
includes /usr and has some GB free space.
MfG
Goswin
--
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/87d35jkyvq.fsf@frosties.localnet
