Re: how to increase space for tmpfs /tmp
On Sun, Mar 25, 2012 at 12:09 AM, Stan Hoeppner <email@example.com> wrote:
> On 3/24/2012 4:02 PM, Javier Vasquez wrote:
>> 2012/3/24 shirish शिरीष <firstname.lastname@example.org>:
>>> # TMPFS_SIZE: maximum size for all tmpfs filesystems if no specific
>>> # size is provided. If no value is provided here, the kernel default
>>> # will be used.
>> See, this is as you wish. This particular setting is the maximum for
>> ALL of the tmpfs space. Kind of the default if nothing else is
>> specified. You might not touch this if you don't want. So I would
>> not be afraid of using 100% of RAM here.
> That's probably not a smart idea:
> tmpfs has three mount options for sizing:
> size: The limit of allocated bytes for this tmpfs instance. The
> default is half of your physical RAM without swap. If you
> oversize your tmpfs instances the machine will deadlock
> since the OOM handler will not be able to free that memory.
Hmm, but you omitted swapping. Using your same link, you'll see that
you can use whole RAM, and that doesn't mean oversizing, specially
with the OP swap size...
First some more data form the link:
tmpfs puts everything into the kernel internal caches and grows and
shrinks to accommodate the files it contains and is able to swap
unneeded pages out to swap space. It has maximum size limits which can
be adjusted on the fly via 'mount -o remount ...'
If you compare it to ramfs (which was the template to create tmpfs)
you gain swapping and limit checking.
Since tmpfs lives completely in the page cache and on swap, all tmpfs
pages currently in memory will show up as cached. It will not show up
as shared or something like that. Further on you can check the actual
RAM+swap use of a tmpfs instance with df(1) and du(1).
So yes, one needs to be careful, not to oversize your tmpfs. That's
completely true, but the limit is not physical RAM, it is actually
RAM+Swap, as I mentioned before.
On this thread, it is asked about how to got with huge files to be
handled by tmpfs, well, debian still gives the option to set /tmp as a
regular partition for example, but if you also have enough swap space,
then by setting the right tmpfs size, you can still get away with it
through tmpfs. Actually in this case I suggested 2g or even 3g for
tmpfs, which was discarded because it sounded dangerous at first by
looking only at RAM, and not considering at all the available swap,
which in my mind and experience is a mistake.
> The OP would likely be far better off simply mounting /tmp on his root
> filesystem as was always done in the past.
I don't agree. Actually the OP has plenty of swap, so he could get
away with 2g or 3g of tmpfs with no risk.
> Application developers
> writing to /tmp aren't expecting memory speed transfers of such files
> because of the traditional placement of /tmp. And he'll have more than
> enough space, many times his RAM quantity.
This is true, but his swap area already provides that in his case.
> FWIW, my Squeeze servers are all upgrades going back to Sarge, IIRC.
> Here's my /tmp setup:
> $ df /tmp
> Filesystem Type Size Used Avail Use% Mounted on
> /dev/sda2 ext2 33G 3.8G 28G 12% /
> I'm sure some/many of you will gasp at that fact I still use EXT2. If
> it ain't broke, don't "fix" it. The /boot and root filesystems are on
> EXT2, with all data storage on XFS. Never had problems with EXT2 in
> this setup, so it lives on, for now.
Just in case, although totally OT, I use ext4 for everything, and I
don't have any problems, :-) And before tmpfs, I kept /tmp in ext4
then, without problems either, so I don't think there's need to
specially recommend ext2. But this is opinion based on self
And I'm sorry to reply even though it has been asked to close the
thread, but I believe there's need to realize that we're not talking
just about RAM.
And on small RAM boxes, things can still work with enough swap, and
for them there was a rule of thumb that said one needed to double at
least the RAM size, and one can play then with total of 3 times RAM
The same way people is recommending disk partitions, one could
recommend increase of swap space, whether through more swap partitions
or even swap files (there's no need to create new partitions for
swapping). And one can always change whatever wanted...
I think this time I won't come back to the thread, :-)