For all the tmpfs mounts, "Avail" is an artificial limit. The default size for tmpfs mounts is half your RAM. It can be adjusted at mount time. (
man mount, scroll to
The mounts don't share the same space, in that if you filled the
/dev would not show any more "Used", and it would not necessarily stop you from writing data to
(Someone could contrive
tmpfs mounts that share space by bind-mounting from a single tmpfs. But that's not how any of these mounts are set up by default).
They do share the same space, in that they're both backed by the system memory. If you tried to fill both
/dev, you would be allocating space equal to your physical RAM. Assuming you have swap space, this is entirely possible. However it's generally not a good idea and would end poorly.
This doesn't fit well with the idea of having multiple user-accessible tmpfs mounts. I.e.
/tmp on many systems. It arguably would be better if the two large mounts shared the same space. (Posix SHM is literally an interface to open files on a user-accessible tmpfs).
/sys/fs/cgroups are system directories. They should be tiny, not used for sizeable data and so not cause a problem. Debian (8) seems to be a bit better at setting limits for them; on a 500MB system I see them limited to 10, 100, 250 MB, and another 5 for
/run has about 2MB used on my systems. systemd-journal is a substantial part of it, and by default may grow to 10% of "Avail". (
RuntimeMaxUse option), which doesn't fit my model.
I would bet that's why you've got 50MB there. Allowing the equivalent of 5% of physical RAM for log files... personally it's not a big problem in itself, but it's not pretty and I'd call it a mistake / oversight. It would be better if a cap was set on the same order as that 2MB mark.
At the moment it suggests the size for
/run should be manually set for every system, if you want to prevent death by a thousand bloats. Even 2% (from my Debian example) seems presumptuous.