Mounting /tmp as a btrfs subvolume

I was running out of space in /tmp when it was mounted as tmpfs and it was causing lots of problems for my system. So I am trying to mount it as a btrfs subvolume based on this seemingly simple advice given here: https://en.opensuse.org/openSUSE:Tmp_on_tmpfs#Using_disk_space_for_/tmp

First I remove everything in /tmp

rm -rf /tmp

then I create the subvolume

btrfs subvolume create /.subvolumes/tmp

And then I add my fstab entry the same as everything else:

UUID=... /tmp btrfs subvol=/.subvolumes/tmp,defaults,noatime,space_cache=v2,compress=zstd,discard=async,ssd 0 0

Reboot fails, and in the admin console all I see is that it can’t be mounted during the tmp.mount systemd unit. The /tmp directory has been made with a few .*-unix files in it.

What is going on?

And if anyone knows the proper way to set this up it would be greatly appreciated.

  • Mount root subvolume: mount -o subvolid=5 /dev/nvme0n1p2 /mnt
  • Create subvolume: btrfs subvolume create /mnt/@/tmp
  • Create fstab entry:
**erlangen:~ #** grep /tmp /etc/fstab  
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  **/tmp**                    btrfs  subvol=/@**/tmp**                 0  0 
**erlangen:~ #**

@salotz Hi and welcome to the Forum :slight_smile:

It seems to me that if your /tmp is filling up, then there are some more issues afoot as to why this is happening… what files are being created and sizes should be looked at.

Thank you for the response!

WhenI try this I cannot create the subvolume:

ERROR: cannot access '/mnt/@': No such file or directory

My understanding of the btrfs interface is still a bit spotty so I could be missing something obvious. I do find it odd that it won’t let me create subvolumes without them being mapped to a particular subdirectory. The special ‘@’ is nowhere in my subvolumes if I list them out except for a subvolume ‘@swap’. I am using the vanilla configuration on Tumbleweed, and I’ve seen the ‘@’ convention used in other distros/guides such as the arch wiki and btrfs docs itself but I figured OpenSUSE had its own conventions.

I understand the concern, however there are a number of reasons why I do not want to use tmpfs. First of all is that I am running out of space just using the normal apps that I expect to use: chrome, doom emacs, etc. Its probably true that they are abusing /tmp but I think most apps still expect /tmp to be a somewhat larger volume than is available in RAM alongside a couple of memory hungry applications all running at once. In any case its not something I can fix (or am willing to fix) except by not using those apps and when /tmp does fill up applications and the desktop start to fail in strange ways that are hard to follow back to the source. Second, I run on fast SSDs so and I don’t really think the performance benefits of running out of tmpfs RAM are that impactful. If I have particular applications that benefit I will go the distance to set up special tmpfs mounts for them, and configure their temporary directories etc. For my desktop I’d rather it just work and using a disk on Ubuntu before I moved to Tumbleweed was perfectly satisfactory on newer hardware. Third, I will be using applications that do use a lot of /tmp space for doing compilations of large software projects and without significant upgrades and excessive configuration fiddling I will definitely run out of /tmp space and so I will just get ahead of the problem now.

If you have any more specific recommendations of common mistakes that newbies make that will improve performance/usage in any case I’d be glad to go over them.

Hi
Well my usage of /tmp is 616K… I run chrome, claws-mail, hexchat and slack, but I’m compiling applications (but rpms on a separate partition), and do compile/run some cuda stuff as well as run virtual machines (k3s clusters) etc.

You should be able to setup a watch on /tmp to see which applications are using it more?

What does the following show?


mount | grep tmpfs

Your talk is murky. Show the subvolumes as follows:

**erlangen:~ #** btrfs subvolume list -t / 
ID      gen     top level       path 
--      ---     ---------       ---- 
256     445677  5               @ 
257     446528  256             @/var 
258     446160  256             @/usr/local 
259     443965  256             @/srv 
260     446204  256             @/root 
261     446178  256             @/opt 
262     446529  256             @/home 
263     443546  256             @/boot/grub2/x86_64-efi 
264     418741  256             @/boot/grub2/i386-pc 
265     446214  256             @/.snapshots 
2053    446527  265             @/.snapshots/1453/snapshot 
2181    434262  265             @/.snapshots/1571/snapshot 
2182    435390  265             @/.snapshots/1572/snapshot 
2183    435422  265             @/.snapshots/1573/snapshot 
2184    435424  265             @/.snapshots/1574/snapshot 
2189    438680  265             @/.snapshots/1579/snapshot 
2190    438841  265             @/.snapshots/1580/snapshot 
2191    439338  265             @/.snapshots/1581/snapshot 
2192    439350  265             @/.snapshots/1582/snapshot 
2193    441561  265             @/.snapshots/1583/snapshot 
2194    441636  265             @/.snapshots/1584/snapshot 
2195    441645  265             @/.snapshots/1585/snapshot 
2196    441647  265             @/.snapshots/1586/snapshot 
2197    441851  265             @/.snapshots/1587/snapshot 
2198    441862  265             @/.snapshots/1588/snapshot 
2199    442600  265             @/.snapshots/1589/snapshot 
2200    442602  265             @/.snapshots/1590/snapshot 
2201    442604  265             @/.snapshots/1591/snapshot 
2202    442606  265             @/.snapshots/1592/snapshot 
2203    442609  265             @/.snapshots/1593/snapshot 
2204    442612  265             @/.snapshots/1594/snapshot 
2205    443363  265             @/.snapshots/1595/snapshot 
2206    443545  265             @/.snapshots/1596/snapshot 
2207    445176  265             @/.snapshots/1597/snapshot 
2208    445377  265             @/.snapshots/1598/snapshot 
2209    445580  265             @/.snapshots/1599/snapshot 
2210    445585  265             @/.snapshots/1600/snapshot 
2211    446203  265             @/.snapshots/1601/snapshot 
2212    446213  265             @/.snapshots/1602/snapshot 
**erlangen:~ #**

Just as I described:

$ sudo btrfs subvolume list -t /ID	gen	top level	path	
--	---	---------	----	
257	157271	5		home
258	154124	5		root
259	157271	5		var
260	152987	5		@swap
261	157271	5		.snapshots
262	157208	257		home/.snapshots
264	45	262		home/.snapshots/1/snapshot
266	49	261		.snapshots/3/snapshot
267	1740	261		.snapshots/4/snapshot
269	1749	262		home/.snapshots/2/snapshot
272	1755	261		.snapshots/7/snapshot
273	1766	261		.snapshots/8/snapshot
277	1774	262		home/.snapshots/3/snapshot
278	1776	262		home/.snapshots/4/snapshot
279	1778	262		home/.snapshots/5/snapshot
280	1778	261		.snapshots/12/snapshot
286	1807	262		home/.snapshots/6/snapshot
287	1809	262		home/.snapshots/7/snapshot
288	1818	262		home/.snapshots/8/snapshot
291	1834	262		home/.snapshots/9/snapshot
295	2000	261		.snapshots/21/snapshot
296	1897	262		home/.snapshots/11/snapshot
300	1975	262		home/.snapshots/13/snapshot
302	1999	261		.snapshots/25/snapshot
303	157271	261		.snapshots/26/snapshot
334	3409	262		home/.snapshots/39/snapshot
452	6092	261		.snapshots/30/snapshot
453	6316	261		.snapshots/31/snapshot
463	6390	262		home/.snapshots/158/snapshot
464	6414	262		home/.snapshots/159/snapshot
468	6419	262		home/.snapshots/160/snapshot
472	6465	262		home/.snapshots/162/snapshot
652	23001	262		home/.snapshots/307/snapshot
903	48195	261		.snapshots/91/snapshot
904	48197	261		.snapshots/92/snapshot
1047	64640	261		.snapshots/93/snapshot
1048	64660	261		.snapshots/94/snapshot
1050	64705	261		.snapshots/95/snapshot
1051	64712	261		.snapshots/96/snapshot
1055	64845	261		.snapshots/99/snapshot
1056	64847	261		.snapshots/100/snapshot
1106	70625	261		.snapshots/101/snapshot
1107	70631	261		.snapshots/102/snapshot
1111	70653	261		.snapshots/105/snapshot
1112	70656	261		.snapshots/106/snapshot
1113	70659	261		.snapshots/107/snapshot
1114	70665	261		.snapshots/108/snapshot
1115	70672	261		.snapshots/109/snapshot
1116	70674	261		.snapshots/110/snapshot
1428	106855	262		home/.snapshots/1051/snapshot
1620	129232	262		home/.snapshots/1243/snapshot
1644	132009	262		home/.snapshots/1267/snapshot
1668	134792	262		home/.snapshots/1291/snapshot
1683	136441	261		.snapshots/111/snapshot
1684	136443	261		.snapshots/112/snapshot
1688	136793	261		.snapshots/113/snapshot
1689	138514	261		.snapshots/114/snapshot
1690	138528	261		.snapshots/115/snapshot
1691	139108	261		.snapshots/116/snapshot
1697	139665	261		.snapshots/117/snapshot
1698	139668	261		.snapshots/118/snapshot
1699	139716	261		.snapshots/119/snapshot
1700	139721	261		.snapshots/120/snapshot
1701	139741	261		.snapshots/121/snapshot
1702	139745	261		.snapshots/122/snapshot
1703	139747	261		.snapshots/123/snapshot
1704	139749	261		.snapshots/124/snapshot
1706	139896	262		home/.snapshots/1315/snapshot
1730	142721	262		home/.snapshots/1339/snapshot
1751	145192	261		.snapshots/125/snapshot
1752	145209	261		.snapshots/126/snapshot
1756	145565	262		home/.snapshots/1363/snapshot
1780	148388	262		home/.snapshots/1387/snapshot
1794	150006	261		.snapshots/127/snapshot
1795	150008	261		.snapshots/128/snapshot
1798	150254	261		.snapshots/129/snapshot
1799	150256	261		.snapshots/130/snapshot
1800	150259	261		.snapshots/131/snapshot
1801	150261	261		.snapshots/132/snapshot
1802	150265	261		.snapshots/133/snapshot
1803	150269	261		.snapshots/134/snapshot
1804	150272	261		.snapshots/135/snapshot
1805	150275	261		.snapshots/136/snapshot
1814	151226	262		home/.snapshots/1411/snapshot
1828	152801	261		.snapshots/137/snapshot
1829	152804	261		.snapshots/138/snapshot
1838	152947	261		.snapshots/145/snapshot
1852	153068	261		.snapshots/146/snapshot
1853	153078	261		.snapshots/147/snapshot
1854	153137	262		home/.snapshots/1428/snapshot
1878	155833	262		home/.snapshots/1452/snapshot
1879	155947	262		home/.snapshots/1453/snapshot
1880	156061	262		home/.snapshots/1454/snapshot
1881	156175	262		home/.snapshots/1455/snapshot
1882	156289	262		home/.snapshots/1456/snapshot
1883	156403	262		home/.snapshots/1457/snapshot
1884	156520	262		home/.snapshots/1458/snapshot
1885	156635	262		home/.snapshots/1459/snapshot
1886	156749	262		home/.snapshots/1460/snapshot
1887	156863	262		home/.snapshots/1461/snapshot
1888	156978	262		home/.snapshots/1462/snapshot
1889	157093	262		home/.snapshots/1463/snapshot
1890	157208	262		home/.snapshots/1464/snapshot
1891	157268	261		.snapshots/148/snapshot
1892	157271	261		.snapshots/149/snapshot

Its hard to post text to a web forum when you only have a console.

Hi
Just use susepaste and send back the url…


btrfs subvolume list -t / | susepaste -n "salotz" -t "btrfs subvolume" -e 0 

Pasted as:
   https://susepaste.org/34204942
   https://paste.opensuse.org/34204942
Link is also in your clipboard.

Nice missed that one in the FAQ and didn’t realize there was a CLI!

I reiterate: Your description in post #1 is murky.

My understanding of the btrfs interface is still a bit spotty so I could be missing something obvious.

I agree.

I do find it odd that it won’t let me create subvolumes without them being mapped to a particular subdirectory.

I converted all my systems to btrfs and I am fine with managing and maintaining these systems since years. However I fail to grasp the meaning of the above. Can you elaborate?

I am using the vanilla configuration on Tumbleweed, and I’ve seen the ‘@’ convention used in other distros/guides such as the arch wiki and btrfs docs itself but I figured OpenSUSE had its own conventions.

Subvolumes of your system are quite different from openSUSE defaults: Expert Partitioner | Reference | openSUSE Leap 15.5 I suggest you reconsider switching to defaults which are working fine for virtually everybody.

Reboot, wait until it fails to mount and post full output of “journalctl -b”. Upload to https://susepaste.org.

Well, that is kind of why I am asking in the forum. I did not do any extra configuration of the subvolumes AFAICT. I am using the stock options, so this confirms that this could be part of the problem. I thought it was strange that it wasn’t closer to the subvolumes you describe but I was just hoping to trust the good defaults for btrfs snapshotting which was one reason I switched to OpenSUSE. Maybe I’ll go through the installation again on another machine just to double check that I didn’t do anything out of the ordinary.

Now unrelated to my actual problem, and more your concerns with me not making sense:

I converted all my systems to btrfs and I am fine with managing and maintaining these systems since years. However I fail to grasp the meaning of the above. Can you elaborate?

Right I’m sure there is a “happy path” but not having used btrfs or OpenSUSE for many years I’m not on it. Presumably people come to the forums to get that kind of help and get to the level of familiarity that you are at so I don’t think it would be too difficult to imagine yourself in my shoes. I will elaborate on this particular issue.

I have a default subvolume / which is mounted to / on my system. I want to add a new /tmp subvolume (where this is a subvolume path and the actual mounted filesystem pattern) . The least surprise interface would be that btrfs internal constructs are separate from the specific mapping of them to the filesystem that is being worked on. So I though that btrfs subvolume create /tmp would create only a subvolume which I can then mount when and where I see fit. I.e. I create the subvolume-path (not actual filesystem path) /tmp, write my fstab entry, and then reboot and have the subvolume mounted at /tmp.

The actual behavior is to create a subvolume for the btrfs filesystem using a real filesystem path that is then translated to a subvolume-path. For example, if I have a filesystem test and I want to create a subvolume in it, I first have to mount it at e.g. /misc/test then create it using a path relative to this btrfs subvolume create /misc/test/new. Why can I not just write btrfs subvolume create test /new or something similar? Why do I have to first mount it?

This caused me a long time of debugging where I had / subvolume path mounted at / and I want to create /tmp subvolume path, but there is already a /tmp folder (that I cannot remove while the desktop is running) and I could not create the subvolume. So the trick is to mount / somewhere and then create the subvolume.

Thats all, its just overly confusing and it doesn’t seem like there is a clear reason for this interface. Nor is there any guide to tell you things work like this.

I agree.

Thank you for helping, but you don’t have to be so condescending about it. I’m aware I don’t know what I’m doing and I’m giving as much information as I can about the specific problem and where I may be missing knowledge.

Becasuse “btrfs subvlume” works with mounted filesystem. It is implemented this way.

I recommend doing so and use expert partitioner’s default subvolumes: Installation steps | Start-Up | openSUSE Leap 15.5

Right I’m sure there is a “happy path” but not having used btrfs or OpenSUSE for many years I’m not on it. Presumably people come to the forums to get that kind of help and get to the level of familiarity that you are at so I don’t think it would be too difficult to imagine yourself in my shoes. I will elaborate on this particular issue.

I have a default subvolume / which is mounted to / on my system. I want to add a new /tmp subvolume (where this is a subvolume path and the actual mounted filesystem pattern) . The least surprise interface would be that btrfs internal constructs are separate from the specific mapping of them to the filesystem that is being worked on. So I though that btrfs subvolume create /tmp would create only a subvolume which I can then mount when and where I see fit. I.e. I create the subvolume-path (not actual filesystem path) /tmp, write my fstab entry, and then reboot and have the subvolume mounted at /tmp.

The actual behavior is to create a subvolume for the btrfs filesystem using a real filesystem path that is then translated to a subvolume-path. For example, if I have a filesystem test and I want to create a subvolume in it, I first have to mount it at e.g. /misc/test then create it using a path relative to this btrfs subvolume create /misc/test/new. Why can I not just write btrfs subvolume create test /new or something similar? Why do I have to first mount it?

This caused me a long time of debugging where I had / subvolume path mounted at / and I want to create /tmp subvolume path, but there is already a /tmp folder (that I cannot remove while the desktop is running) and I could not create the subvolume. So the trick is to mount / somewhere and then create the subvolume.

Thats all, its just overly confusing and it doesn’t seem like there is a clear reason for this interface. Nor is there any guide to tell you things work like this.

Thank you for helping, but you don’t have to be so condescending about it. I’m aware I don’t know what I’m doing and I’m giving as much information as I can about the specific problem and where I may be missing knowledge.

Whenever you want to create a subvolume the path may not exist already. You may boot into a rescue system and mount your system at /mnt. Run “rmdir /mnt/tmp”, “btrfs subvolume create /mnt/tmp” and fix /mnt/etc/fstab accordingly.