FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-27-2012, 10:50 PM
Serge
 
Default Idea: mount /tmp to tmpfs depending on free space and RAM

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.

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?

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.

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenEp6C0QF+K3OLw_jLYkza9qSGd8du4LBrAayp1SM9WaG7 w@mail.gmail.com">http://lists.debian.org/CAOVenEp6C0QF+K3OLw_jLYkza9qSGd8du4LBrAayp1SM9WaG7 w@mail.gmail.com
 
Old 06-01-2012, 12:19 PM
Goswin von Brederlow
 
Default Idea: mount /tmp to tmpfs depending on free space and RAM

Serge <sergemdev@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d35jkyvq.fsf@frosties.localnet">http://lists.debian.org/87d35jkyvq.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 09:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org