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

Reply via email to