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:
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.
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.
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?
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.
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.
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.
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.
