> 1. every tmpfs mount is considered to each have as much free space as there is RAM in the system (total RAM, not free RAM!) This is wrong as can be seen from

> 1. every tmpfs mount is considered to each have as much free space as there is RAM in the system (total RAM, not free RAM!) This is wrong as can be seen from the output of `df -h -t tmpfs` on a Linux system: df -t tmpfs -h Filesystem Size Used Avail Use% Mounted on tmpfs 22G 168K 22G 1% /dev/shm tmpfs 8,6G 2,2M 8,6G 1% /run tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 4,3G 464K 4,3G 1% /run/user/1000 Every tmpfs has a different size / available space. > 2. the "used space" stat will track unlinked-but-open files, which for a tmpfs shouldn't be thought of as even being "in" the tmpfs at that point This is also wrong as they still count against the space the given tmpfs might use. That is relevant information when something reports ENOSPACE. > If you want to know the disk usage of a tmpfs dir, use du(1). This number is usually irrelevant. > > If /run is already a tmpfs mount point, why does /run/lock have to be one as well? > > I believe this is a long-term deprecation caught in mid-transition This is wrong too. /run/lock is a separate tmpfs as /run/lock is world-writable, but /run is not. It's basically to prevent denial of service by using the world-writable /run/lock to fill the /run tmpfs. Which separate tmpfs for /run and /run/lock this is no longer possible for all users. This is also why /run/user/X is a separate tmpfs.