Re: /tmp as tmpfs and consequence for imaging software
Roger Leigh <firstname.lastname@example.org> writes:
> On Wed, Nov 16, 2011 at 11:56:40AM +0100, Goswin von Brederlow wrote:
>> Roger Leigh <email@example.com> 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.
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