On Wed, Nov 16, 2011 at 11:56:40AM +0100, Goswin von Brederlow wrote: > Roger Leigh <rle...@codelibre.net> writes: > > > As touched on in the bug report, I think that being able to store > > 1.2GiB on /tmp is an unrealistic expectation. To qualify, I mean > > to expect that to work *by default*. If you want to store such > > large amounts of data, you will need to configure your system to > > handle that, either by: > > > > - provisioning of more swap and raising of the TMP_SIZE limit. > > - disabling RAMTMP and using a disc-backed filesystem (either the > > rootfs or dedicated /tmp mount). > > > > Again, as mentioned in the report, due to the wide variation in > > disc partitioning, filesystem utilisation and RAM capacity between > > systems, we don't currently make *any* guarantees regarding a > > minimum amount of space available in /tmp, when using a disc-backed > > /tmp. If the rootfs fills up, /tmp will cease to allow creation of > > new files. When using tmpfs, we do at least make a minimum > > guarantee of having a certain amount of storage available (which > > might albeit be used by other users). > > Correct me if I'm wrong but doesn't having a real filesystem for /tmp in > /etc/fstab prevent tmpfs from being mounted there?
Not currently. The logic is that a tmpfs is mounted on /tmp if - RAMTMP=yes, or - fstab contains an entry for a tmpfs on /tmp, or - root is readonly An fstab entry for a non-tmpfs on /tmp won't currently prevent the tmpfs from being mounted (it will be hidden underneath). This would require setting RAMTMP=no. We could certainly improve the logic here to make this a bit more robust. This is only the case where you have an fstab entry /and/ RAMTMP=yes, or you have two /tmp entries in /etc/fstab (one tmpfs and one not), so is really only misbehaving when misconfigured. 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. -- 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/20111117003811.gr30...@codelibre.net
