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.
signature.asc
Description: Digital signature
