[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /tmp as tmpfs and consequence for imaging software



Roger Leigh <rleigh@codelibre.net> writes:

> On Wed, Nov 16, 2011 at 11:56:40AM +0100, Goswin von Brederlow wrote:
>> Roger Leigh <rleigh@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



Reply to: