1

I wondered, what would happen, if more tmpfs space is assigned than there is physical memory - and they are filled.


More in-detail:

Suppose I have 4GB RAM, 4GB swap.

mount -o size=4G -t tmpfs tmpfs /mnt1
mount -o size=4G -t tmpfs tmpfs /mnt2
mount -o size=4G -t tmpfs tmpfs /mnt3

As far as I understand, there is no problem, since these devices do not actually allocate the memory they were assigned from the get-go.

Now I start to write on these:

cat /dev/zero >/mnt1/bla &
cat /dev/zero >/mnt2/bla &
cat /dev/zero >/mnt3/bla &

and...


Questions:

I wondered, how the system should handle this?

I did not find anything on it, but when I mount tmpfs multiple times, do I mount the same device over-and-over under the hood, or different, totally independent device instances are created?

Am I somehow prevented from crashing my system, or am I free to do it this way?

The underlying reason I started to ponder it, when assigning tmpfs to /tmp:

  1. one approach is mounting directly,
  2. the other is to create a file in /dev/shm, and bind mount that.

If there is no limit assigning tmpfs space, 2. - bind mounting - is probably an inherently safer option, if I want to make extensive use of tmpfs, but don't want to spend too much time thinking through the consequences of my actions.

2

The machine will crash. End of story. (*)

It's up to the system administrator to give sane size limits across all tmpfs instances.

tmpfs is great and makes "ramdisks" simple, but one thing to be aware of is that tmpfs does not have a global size limit but a size limit per mounted instance.

The OOM kill cannot reclaim space occupied by tmpfs. At most it can be swapped out, but only if there is enough swap space available.

So, if you mount a tmpfs here, another there, yet another here and yet another there... and each has a limit of several gigabytes instead of a small size, it's easy to make the machine crash (or send into infinite swap-unswap-reswap loop) simply by filling them all up.

Unfortunately tmpfs defaults to a whopping 50% of RAM (instead of 10M or something that would suffice for many tasks) and also defaults to be world-writable. So it's common to see three or four tmpfs instances that could eat 200% of RAM if filled. Any regular user can crash the system.

Time to visit your /etc/fstab and give them sane limits.


(*)

Now I start to write on these:

cat /dev/zero >/mnt1/bla &

Your example is actually the most harmless one. You're writing zeroes instead of random data, so if you have some simple optimization going on (same page merging or zswap) you could probably still survive that one. Zeroes can be compressed or optimized away in other ways.

You want to write random data. That's not optimizeable, it has to be stored in full.

But then, writing random data is still relatively harmless. Your swap will fill up and if you have enough, that's the end of it. For swapping the best case scenario is never reading back what was swapped out.

So instead of just writing, you'll want to read it too. Then even if your tmpfs is barely covered by both ram and swap, the machine will still be swapping itself to death.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.