Roger Leigh <rle...@codelibre.net> writes: > 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
So RAMTMP=no but a readonly root would mount tmpfs despite having a real /tmp in fstab? That doesn't track with what you say below. > 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 Maybe it could even be so robust that you get a tmpfs when it fails to mount the real fs for whatever reason. That would probably be better than having a non-writable /tmp (assuming / is read-only). E.g. RAMTMP=yes + fstab entry for real FS means tmpfs is used as fallback. MfG Goswin -- 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/87vcqizum9.fsf@frosties.localnet