#1083159 mount: tmpfs size for /tmp is randomly ignored

Package:
systemd
Source:
systemd
Description:
system and service manager
Submitter:
Vincent Lefevre
Date:
2026-01-10 11:06:47 UTC
Severity:
normal
Tags:
#1083159#5
Date:
2024-10-02 12:43:21 UTC
From:
To:
The tmpfs size for /tmp is normally 50%:
/usr/lib/systemd/system/tmp.mount has

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m

But the size is randomly ignored: after some boots,

cventin:~> grep /tmp /proc/mounts
tmpfs /tmp tmpfs rw,nosuid,nodev,nr_inodes=1048576,inode64 0 0

(without a size option), and after others, I get something like

cventin:~> grep /tmp /proc/mounts
tmpfs /tmp tmpfs rw,nosuid,nodev,size=16422180k,nr_inodes=1048576,inode64 0 0

#1083159#10
Date:
2024-10-02 16:54:05 UTC
From:
To:
I don't see why mount is involved here.
#1083159#19
Date:
2024-10-02 23:24:01 UTC
From:
To:
(but it seems that the bug has always been present, i.e. since /tmp
uses tmpfs).

Well, the tmpfs(5) man page mentions the mount command and has
a SEE ALSO mount(8), and it doesn't mention systemd at all. And
the systemd.mount(5) manpage says that it invokes mount(8):

  Additional options are listed in systemd.exec(5), which define the
  execution environment the mount(8) program is executed in, and in
[...]
  systemd passes two parameters to mount(8); the values of What= and
  Where=. When invoked in this way, mount(8) does not read any options
  from /etc/fstab, and must be run as UID 0.
[...]
  Type=
    Takes a string for the file system type. See mount(8) for details.
[...]

and so on.

#1083159#26
Date:
2024-10-02 23:56:11 UTC
From:
To:
I've just reported the bug upstream.
#1083159#33
Date:
2024-10-03 13:29:47 UTC
From:
To:
Summary: On my Debian/unstable machines, a tmpfs file system is
mounted on /tmp with the default size=50% option; this is the
current default in Debian. In this case, /proc/mounts and the
"mount" command (based on /proc/self/mountinfo) do not always
show the resulting size (as a number of KB) for /tmp; this is
random and can change only after a reboot.

#1083159#50
Date:
2025-02-21 19:33:21 UTC
From:
To:
Hi Vincent,

I stumpled over this bug while reviewing open bugs, and my take is
that this is actually not a bug. *But* I hope one of my more
experienced colegues in the team might review this claim.

Let's start from:

https://www.kernel.org/doc/html/latest/filesystems/vfs.html#mount-options

The important bits are:

Showing options
---------------

If a filesystem accepts mount options, it must define show_options() to
show all the currently active options.  The rules are:

  - options MUST be shown which are not default or their values differ
    from the default

  - options MAY be shown which are enabled by default or have their
    default value

tmpfs is defined in "mm/shmem.c and we have (current mainline):

5263 #ifdef CONFIG_TMPFS
5264         .statfs         = shmem_statfs,
5265         .show_options   = shmem_show_options,
5266 #endif

shmem_show_options() handles showming mount options for tmpfs:

4878 static int shmem_show_options(struct seq_file *seq, struct dentry *root)
4879 {
4880         struct shmem_sb_info *sbinfo = SHMEM_SB(root->d_sb);
4881         struct mempolicy *mpol;
4882
4883         if (sbinfo->max_blocks != shmem_default_max_blocks())
4884                 seq_printf(seq, ",size=%luk", K(sbinfo->max_blocks));
[...]

So size is only showed if sbinfo->max_blocks != shmem_default_max_blocks().

Let's look at shmem_default_max_blocks():

 147 #ifdef CONFIG_TMPFS
 148 static unsigned long shmem_default_max_blocks(void)
 149 {
 150         return totalram_pages() / 2;
 151 }

So this is 50% of ram as *default* which matches tmpfs(5):

   Mount options
       The tmpfs filesystem supports the following mount options:

       size=bytes
              Specify  an  upper  limit  on the size of the filesystem.
              The size is given in bytes,  and  rounded  up  to  entire
              pages.  The limit is removed if the size is 0.

              The size may have a k, m, or g suffix for Ki, Mi, Gi (bi‐
              nary  kilo  (kibi),  binary  mega (mebi), and binary giga
              (gibi)).

              The size may also have a % suffix to limit this  instance
              to a percentage of physical RAM.

              The  default,  when  neither size nor nr_blocks is speci‐
              fied, is size=50%.

So my undestanding would be that the code here is coherent with the
specification that if size corresponds to the default value, the code
may, but does not must show it.

Does this make sense?

Regards,
Salvatore

#1083159#57
Date:
2025-05-06 10:13:24 UTC
From:
To:
Sorry, I forgot to reply...

But, IMHO, a fixed choice should be made. This should not be random.
Otherwise, this is confusing, and can break scripts that detect
changes in the configuration.

Now, with your analysis of the code...

According to the above code, the size is never shown for the default
as the condition sbinfo->max_blocks != shmem_default_max_blocks() is
false. But this is not what I observe: the size is shown randomly
(more precisely, whether the size is shown is chosen at boot time),
though it is always the default here.

#1083159#62
Date:
2025-05-06 10:54:17 UTC
From:
To:
[...]
[...]

The bug may be the use of totalram_pages(), while the documentation
says:
[...]
                                     ^^^^^^^^^^^^

According to https://stackoverflow.com/a/60882958/3782797 (and
the answer given b MistralAI) it is get_num_physpages() that
gives the whole physical memory.

I suspect that totalram_pages() is not constant over the time,
so using it is buggy as there is no way for the user to know
what size is actually used for the 50% default.

#1083159#71
Date:
2026-01-10 10:10:54 UTC
From:
To:
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.

#1083159#76
Date:
2026-01-10 10:10:54 UTC
From:
To:
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.