[Pkg-sysvinit-devel] Bug#630615: Bug#630615: RAMTMP should default to no
Roger Leigh
rleigh at codelibre.net
Wed Jun 15 20:46:20 UTC 2011
On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote:
> On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote:
> > [Michael Biebl]
> > > the default for new installations is to use RAMTMP=yes.
> >
> > Hm, do not remember doing this change. Anyone know when it happened?
>
> This was done as part of the /run work a couple of months back.
>
> This was done following the discussion about default size limits
> for the various tmpfses in use (/run, /run/lock, /run/shm, and
> /tmp) on the debian-devel list, and also on #debian-devel. At
> the time, the consensus appeared to be generally in favour of
> the change.
I'll follow up to the other messages in this one mail.
Discussion on -devel (all in the same thread):
http://lists.debian.org/debian-devel/2011/04/msg00554.html
http://lists.debian.org/debian-devel/2011/04/msg00615.html
http://lists.debian.org/debian-devel/2011/04/msg00703.html
Note that the dicussion at the time was not initially
proposing to make it the default, merely a configurable option,
but consenus appeared to change in favour of making it the
default as well. I don't have any IRC logs from the time in
question I'm afraid. It might have been mentioned in other
threads as well.
The FHS defines the persistence/lifetime for /tmp and /var/tmp.
It does not make any recommendations about size.
/tmp contents are not guaranteed to be preserved across reboots
/var/tmp contents are preserved across reboots (but may still
be cleaned after a certain time duration).
Historical practice is that /tmp is small, and /var/tmp is
rather larger. When using Sun/Solaris systems back around 2000,
/tmp was always a tmpfs (it's the default), and /var/tmp was
disc. Solaris tmpfs didn't have size limits (filling it would
hang the system--I remember an undergrad being told off for
trying to download a RedHat ISO image to /tmp and killing the
system). On these systems files in /tmp were cleaned hourly,
and files in /var/tmp weekly. Files needing longer-term storage
went in /var/preserve (cleaned every few months) or on other
storage.
There are three possibilities for /tmp:
- as a subdirectory of the root filesystem
- as a separately mounted filesystem
- as a tmpfs
All three have pros and cons.
1) Subdirectory of the root filesystem
This can be a very large filesystem if you install using just
one large filesystem, or with /home separate. But it's not
guaranteed.
Example: rootfs contains only / and /usr:
% df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/ravenclaw-root
9611492 8364556 758696 92% /
% df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/hufflepuff-root
19223252 7026936 11219832 39% /
Allowing for the 5% reserved blocks, the first doesn't have
much free space to accommodate /tmp at all. The second has many
gigabytes free though (despite being a much smaller system).
The point I'm trying to make here is that there are no guarantees
at all about how much free space the root filesystem has to
accomodate /tmp. And changes in usage post-install may greatly
reduce its capacity.
2) Separately mounted filesystem
This needs manual setup: a filesystem needs making, and this needs
mounting in /etc/fstab. Its size is exactly as large as the admin
chooses.
3) As a tmpfs
The default size is 20% of the core memory.
This may vary significantly depending upon the amount of memory
installed in the system:
% mount | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=1639592k)
% df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 1639592 60 1639532 1% /tmp
% mount | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=206248k)
% df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 206248 0 206248 0% /tmp
This is using the same two examples as above. The systems have
8 GiB and 1 GiB core memory, respectively.
Customisation: just add an fstab entry like this:
tmpfs /tmp tmpfs nosuid,nodev,size=8g,mode=1777 0 0
(note, this is all documented)
This requires that you have the memory and/or swap to back the
size specified.
The bug:
The RAMTMP feature as implemented is working exactly as designed. It
is not buggy in itself. The question is whether it should be the
default or not.
Expectations:
What is the minimum size that an application should expect /tmp to
be, and how much of that space should an application expect to be
available to satisfy its needs?
Tricky question. The simple fact of the matter is, however, we
don't make /any/ guarantees regarding minimum size and available
space. Depending upon the partitioning scheme used, and the free
space on the partition containing /tmp, there may be GiB of free
space, or little or no space at all. Other applications and users
may use all the space leaving nothing for you.
In the IRC discussion, it was mentioned that some DVD authoring
applications were using /tmp to create/store 4GiB disc images.
Also, backup software used /tmp to store multi-gigabyte backups
during its operation. I would argue that any application expecting
to be able to store such large files in /tmp has wholly unrealistic
expectations. The admin may configure the system such that /tmp
can meet these demands, but to expect the default to meet them is
impossible. This isn't specific to /tmp as a tmpfs; we don't make
these guarantees with disc-backed filesystems either. Though I will
allow that, depending upon the partitioning scheme used, a disc-
based filesystem /may/ allow for much larger file sizes (but this
is not guaranteed).
In contrast to disc-based filesystems, which may be filled up,
tmpfs does offer certain guarantees. Because it's not shared
with other data (like if on the rootfs) it's dedicated for /tmp
usage alone. This means that (with the default), you are
guaranteed to get a usable filesystem with a size of 20% of the
core memory, and the size is configurable. Additionally, should
it be filled to capacity, you are not going to interfere with the
functioning of the base system. It does have the limitation that
it might not be as big as you require by default, but you can be
certain that there will be some free space there after boot.
Initial setup:
I would like to see the Debian installer support setup of /tmp to
permit
- disabling of /tmp on tmpfs
- setting of a tmpfs size other than 20% core
- allocation of sufficient backing store (swap) during partitioning
If we wanted to guarantee a minimum tmpfs size here, we could ensure
that there's sufficient swap to up the limit from 20% to something
more, or an absolute value rather than a percentage.
I remain convinced that having /tmp on tmpfs will give us a more
reliable system than having /tmp on disc, for the reasons outlined
above. We can certainly make the default size better though.
I would also like us to consider future goals, such as read-only root.
Having tmpfs on /tmp is mandatory when root is read-only, but it
makes sense to have it on tmpfs /anyway/. Having /tmp somewhere
other than the rootfs reduces disc writes, and the chance of disc
corruption. And it also means better I/O performance since programs
creating temporary files will never cause disc writes (unless swapping
is needed), so discs don't need spinning up etc. And it's always
guaranteed to be clean on reboot.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110615/36db497a/attachment-0001.pgp>
More information about the Pkg-sysvinit-devel
mailing list