How I installed every Garuda spin on one partition

How I installed every Garuda spin on one partition

Inspired by @dalto’s post here, for the past few months I have been experimenting with adding multiple Linux installations to a single Btrfs partition using subvolumes. In this topic, I describe how I have installed every Garuda Raptor spin on one partition with this method, using the rEFInd Boot Manager to easily boot to any of the installations, with options for extra kernels and fallback images. In this setup, an option for booting to Grub is preserved as well for easily booting into Snapper snapshots with grub-btrfs.

This topic is largely intended to showcase Btrfs subvolume multibooting and the rEFInd boot manager, but is written in the style of a how-to in case anyone would like to follow along, or adopt a few ideas into their own setup. A much simpler version of this guide, without the rEFInd setup and some of the other steps, has been posted on the Garuda Wiki here: Multiple installations on one partition | Garuda Linux wiki

:warning: Like all multibooting setups, this should be considered not offically supported by the Garuda team. Multibooting adds extra layers of complexity to a system that can make troubleshooting more difficult. Be warned that manipulating subvolumes and bootloader configurations like described in this topic can make your system unbootable if you make a mistake.

Why would anyone do this?

I’ll admit, thirteen installations is a bit much. Keeping them all up to date is bound to grow a little too time consuming. Sooner or later I will let a few of them go to free up some space on the disk.

But that’s just the thing: adding an installation I want to test out–or removing it when I am done–is trivial when the installations are contained in subvolumes. Adding partitions to the disk or resizing filesystems is not needed. You can set up a fresh installation in less than ten minutes, tinker around for an hour or two, and then blow away the subvolumes when you are done and it’s like it was never there.

This provides a nice alternative to testing a distro in a virtual machine. Having the installation “on the metal” often yeilds a better performance, and eliminates the possiblity of unexpected behavior caused by virtualization.

This is also a great way to enjoy having multiple desktop environments. Installing one desktop environment on top of another can cause conflicts and breakages, many of which can be difficult to troubleshoot. Keeping them as separate installations allows you to configure each system as deeply as you wish without having to worry about breaking something on another desktop environment.

Thanks to subvolumes, it is easy to share files or directories between your systems. Multiple systems can share a common subvolume, or If you need something from your other installation that isn’t stored on a shared resource you can always just reach into its subvolume and grab it.

Above all, I found this project to be a fun way to learn more about the interesting and complex features of Btrfs.

Getting started

  • A Btrfs filesystem is needed for this, obviously. One long, contiguous Btrfs partition on your disk is best.
  • An EFI partition is needed as well, since we are using the rEFInd Boot Manager. Systems that boot in legacy (BIOS) mode without an EFI partition can still multiboot with subvolumes, but will need to set it up with Grub only which has some disadvantages (it is much more difficult to organize when you have a lot of installations up, especially the bootable snapshots).
  • Encryption is a perfectly worthy consideration, and is absolutely possible with this kind of setup. However, an encrypted setup is beyond the scope of this topic.

Rename the default subvolumes

Create a mount point outside the top-level subvolumes. In my example here, my Btrfs partition is on nvme0n1p2. Obviously change that to whatever your Btrfs partition happens to be.

sudo mkdir /mnt/top-level_subvolume
sudo mount -o subvolid=0 /dev/nvme0n1p2 /mnt/top-level_subvolume
cd /mnt/top-level_subvolume

Rename all the subvolumes. Replace gnome , gnome_cache, etc with whatever names you wish to use for your subvolumes.

sudo mv @ gnome
sudo mv @cache gnome_cache
sudo mv @home gnome_home
sudo mv @log gnome_log
sudo mv @root gnome_root
sudo mv @srv gnome_srv
sudo mv @tmp gnome_tmp

It is customary to mark these subvolumes with “@”. This convention can be preserved or not depending on your preference. In this setup I have decided not to use “@” in the subvolume names.

Update /etc/fstab

It is important to get your /etc/fstab updated before you reboot. Take extra care to ensure the entries are accurate.

Update the subvol= values to the new names (i.e. subvol=@ should be changed to subvol=gnome, and so on.) For example:

<device>                                  <mount point>  <type>  <options>
UUID=xxxx-xxxx                            /boot/efi      vfat    defaults,noatime 0 2
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /              btrfs   subvol=/gnome,noatime,compress=zstd 0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /home          btrfs   subvol=/gnome_home,noatime,compress=zstd 0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /root          btrfs   subvol=/gnome_root,noatime,compress=zstd 0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /srv           btrfs   subvol=/gnome_srv,noatime,compress=zstd 0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /var/cache     btrfs   subvol=/gnome_cache,noatime,compress=zstd 0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /var/log       btrfs   subvol=/gnome_log,noatime,compress=zstd 0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /var/tmp       btrfs   subvol=/gnome_tmp,noatime,compress=zstd 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

It is not needed, but if you would like you can re-mount the partitions at this point. If there is an error in fstab it should be announced when you remount.

sudo systemctl daemon-reload
sudo mount -a

Update Grub

Change the name of the boot directory from “Garuda” to something else so it won’t create a conflict when you install the next ISO. The next installation will also name the boot directory “Garuda”, which will simply overwrite any directory with the same name (this would make our first installation unbootable).

sudo mv /boot/efi/EFI/Garuda /boot/efi/EFI/Gnome

Change the GRUB_DISTRIBUTOR= line in /etc/default/grub to match whatever you just named the boot directory in /boot/efi/EFI/.

sudo micro /etc/default/grub

If this line does not match the name of a directory in /boot/efi/EFI (the one we just changed above), when you run the grub-install script it will automatically make a completely new directory.

Optionally, disable the Grub OS-prober. OS-prober will not be needed since we will be using rEFInd, and disabling it will make the Grub menu much less crowded when we do boot to Grub for restoring a snapshot.

Find the line that says GRUB_DISABLE_OS_PROBER=false and comment it out by adding a # in front of the line.


Next, run the Grub installation script.

sudo grub-install ...

I have put “...” to mean “add whatever options are specifically relevant for your Grub installation”. In some cases, grub-install or grub-install --no-nvram is enough. If you are not sure, refer to the document here: GRUB - ArchWiki

Regenerate the Grub configuration file.

sudo update-grub

It is fine to reboot here if you wish; at this point you should be all set to get back into your new installation with Grub.

Configure rEFInd

Install the rEFInd package:

sudo pacman -S refind

Run the refind-install script:


Setting up a boot stanza

For the purpose of this topic, I will just set up a quick and easy boot stanza that will chainload the Grub bootloader. This will allow using the rEFInd boot manager to keep the multiple installations organized, without going too in depth regarding boot stanza configuration.

A boot stanza is capable of much more configuration, including booting the installation directly without using Grub at all. For those interested, writing a boot stanza is discussed in more detail in this wiki post: Writing a rEFInd Boot Stanza | Garuda Linux wiki

The rEFInd Config

Open refind.conf in your editor. Since it is on the EFI partition, you will have to open it with sudo or as root.

sudo micro /boot/efi/EFI/refind/refind.conf

Scroll all the way down to the bottom of the file. You will see many boot stanza examples on the way down, with disabled written in as the last option–this is a simple way to disable a boot stanza, instead of commenting out the whole thing line by line.

Find some space in the file to set up your stanza. It can be before or after the example stanzas–it doesn’t really matter, except that whatever order the boot stanzas are in will be the same order the entries appear in the rEFInd menu.

The basic layout of the stanza will look like this:

menuentry Gnome {
    icon    /EFI/refind/gnome_logo.png
    volume  EFI
    loader  /EFI/gnome/grubx64.efi
    graphics on


The menuentry can be named whatever you like, however if it contains a space (more than one word) you must enclose it in quotes (for example, “Garuda Gnome”).

"Show me!"

A menuentry value with no space:

menuentry Gnome {

A menuentry value with a space:

menuentry "Garuda Gnome" {


The icon entry is the path to the icon relative to the EFI partition (i.e. /boot/efi). So to use the Arch icon at /boot/efi/EFI/refind/icons/os_arch.png, you write in the stanza /EFI/refind/icons/os_arch.png.

There is a default icons directory at /boot/efi/EFI/refind/icons, which has an assortment of .pngs for some popular Linux distros, or you can use a custom icon.

[details=““Show me!””]
The easiest way to set up your custom icon is to save it on the EFI partition. I recommend not saving it in /boot/efi/EFI/refind/icons because the directory gets overwritten (rather, saved to a backup file) when the refind-install script is run. You will have to restore the directory to get your icons back in that case.

Instead, either make your own directory or just store them in /boot/efi/EFI/refind. For the latter case, you would describe the path in your stanza like so:

icon	/EFI/refind/MY_CUSTOM_ICON.png

Again, the path is relative to the EFI partition (i.e. relative to /boot/efi/ in a default Garuda setup).


For booting to Grub, the volume entry is the partition name, the filesystem label, or the PARTUUID–not the filesystem UUID–of the EFI partition.

If you named the partition during the installation process (or afterward), just use that because that will be the easiest. Otherwise, you can use blkid to find the PARTUUID and use that instead.

"Show me!"

Run sudo blkid -s PARTUUID -o value /dev/sdXY, where sdXY is the EFI partition.

sudo blkid -s PARTUUID -o value /dev/nvme0n1p1

Or, just run sudo blkid and find the PARTUUID= value for the EFI partition in the output.

Add that value to the volume entry:

menuentry "Garuda Gnome" {
	icon	icon	/EFI/refind/gnome_logo.png
	volume e798748f-c287-43e6-b675-cf376345f211


In the case of booting to Grub, the loader entry points to the grubx64.efi file for that Grub installation. For refind.conf, write the path relative to the EFI partition (for example, /EFI/grub/grubx64.efi).

If you recall, back in the “Update Grub” section earlier in the topic, we renamed /boot/efi/EFI/Garuda to something else (in the example it was changed to /boot/efi/EFI/Gnome). That is the directory we need to point to in this submenu entry–just without the /boot/efi part since it is written relative to the EFI partition instead of the root partition.


The graphics option should be set to on if you wish for rEFInd to boot in graphics-mode. If you don’t set this, Grub will still load but it will be in a low-resolution mode that can make it difficult to see all the options in the menu on certain displays.

That’s all there is to it, the boot stanza is complete!

menuentry Gnome {
    icon    /EFI/refind/gnome_logo.png
    volume  EFI
    loader  /EFI/gnome/grubx64.efi
    graphics on

Again, this is a very simple stanza that will just pass off the boot process to Grub. For more in-depth boot stanza configuration, see the wiki post mentioned above (Writing a rEFInd Boot Stanza | Garuda Linux wiki).

Clean up the Boot menu

After each install, rEFInd will automatically detect the grubx64.efi file on the EFI partition and will add a boot entry for it (it boots to Grub). It typically gets a Tux icon, unless you install a distribution that is associated with an icon in /boot/efi/EFI/refind/icons–in which case it will get whatever the icon is.

Once you have Grub set up as a submenu entry in your boot stanza, these auto-generated boot entries are no longer needed–they only add unnecessary clutter to the boot menu. You can hide them by pressing Delete and confirming on the prompt that you would like to hide that boot option.

This feature doesn’t actually delete anything; you can retrieve the boot option any time you like by entering the “hidden tags” menu and choosing to restore it.

Install a rEFInd theme

Optionally you may install a theme to stylize your rEFInd boot menu however you wish. There are tons of themes available to choose from; check out some of the options available on GitHub here: refind-theme · GitHub Topics · GitHub

In the examples in this topic I am using the “Regular” theme, available here: GitHub - bobafetthotmail/refind-theme-regular

Add another installation

It’s time to install another spin! Boot to the installer from a USB like you would normally do. Choose the manual partitioning option.

Select the EFI partition and click on Edit. Be very careful with the selections you make–you want to keep the contents of the partitions–do not format or you will lose the first installation.

EFI partition:

  • Content: Keep
  • Mount point: /boot/efi

Next, select the Btrfs partition and click on Edit.

Btrfs partition:

  • Content: Keep
  • Mount point: /

:bulb: While you are adding the mount points, consider adding a filesystem label if you haven’t already. You can use the filesystem label instead of the PARTUUID for the volume entry on your boot stanzas.

That’s it! Proceed with the installation.

Once you are booted into the fresh installation, the initial setup is very similar to the first time around; I will summarize in brief anything already explained in more detail above, to have a short version easier to follow along.

Mount the top-level subvolume and rename the new subvolumes–the same process as the first distro, only this time obviously you should pick different names. Replace dr460nized, dr460nized_cache, etc with whatever names you wish to use for your subvolumes, and nvme0n1p2 with whatever your Btrfs partition is.

sudo mkdir /mnt/top-level_subvolume
sudo mount -o subvolid=0 /dev/nvme0n1p2 /mnt/top-level_subvolume
cd /mnt/top-level_subvolume
sudo mv @ dr460nized
sudo mv @cache dr460nized_cache
sudo mv @home dr460nized_home
sudo mv @log dr460nized_log
sudo mv @root dr460nized_root
sudo mv @srv dr460nized_srv
sudo mv @tmp dr460nized_tmp

Edit your /etc/fstab with the new subvolume names.

micro /etc/fstab

Edit the name of the boot directory, and change the GRUB_DISTRIBUTOR line in /etc/default/grub. Disable OS prober by commenting the =false line.

sudo mv /boot/efi/EFI/Garuda /boot/efi/EFI/Dr460nized
sudo micro /etc/default/grub

:bulb: Optional: before regenerating the Grub configuration file, update /etc/default/grub-btrfs/config with the subvolumes to exclude when scanning for snapshots–see “Clean up the snapshots boot menu” below.

Reinstall Grub and regenerate the Grub configuration file.

sudo grub-install --no-nvram
sudo update-grub

Install rEFInd.

sudo pacman -S refind

Set rEFInd as the default bootloader.

sudo refind-mkdefault 
"What's this refind-mkdefault? What happened to refind-install?"

Running the refind-install script is only necessary on the first installation, to get everything set up on the EFI partition and make a NVRAM entry. On subsequent installations, running refind-mkdefault is enough.

refind-mkdefault is a script that checks if rEFInd is the default boot option, and changes it to the default if not–basically an alternative to messing around with efibootmgr. It is handy because if you need to reinstall Grub for any reason it will re-set itself as the default bootloader, and this script will easily fix it for you.

An advanced use of this script would be adding it to a startup task or similar, as described in the man page:

“The intent is that refind-mkdefault can be called after booting via GRUB or some other means to restore rEFInd as the default boot program. It can also be placed in a startup and/or shutdown script to restore rEFInd to its default position automatically. Because it does not re-write the boot order if rEFInd is listed as the first boot entry, this practice should be low in risk.”

There is no harm in running refind-install on every installation (your configs will not be overwritten) but it is overkill and will also restore the icon library to default every time you run it. If you have custom icons you are saving in /boot/efi/EFI/refind/icons, it will save the directory as a backup file and your icons will be gone from your boot screen until you restore it.

Set up your boot stanza in refind.conf.

"Show me!"
sudo micro /boot/efi/EFI/refind/refind.conf
menuentry "Garuda Dr460nized" {
    icon    /EFI/refind/dr460nized_logo.png
    volume  EFI
    loader  /EFI/dr460nized/grubx64.efi
    graphics on

Clean up the snapshots boot menu

Although at this point we have a separate Grub menu for each installation, and OS-prober has been disabled so there are not tons of boot options crowding the menu, there is still an issue with snapshots–namely, all snapshots on all subvolumes are detected and added to each Grub menu.

You may pull up the Cinnamon Grub menu to restore a snapshot, but the Cinnamon snapshots are all intermixed with snapshots from LXQT and Gnome and Sway, and depending on the snapshot limit set in /etc/default/grub-btrfs/config (default is 50) there may not even be that many Cinnamon snapshots to begin with–the 50 snapshot limit gets eaten up by the snapshots from other installations!

To resolve this, open /etc/default/grub-btrfs/config and find this line:

GRUB_BTRFS_IGNORE_PREFIX_PATH=("var/lib/docker" "@var/lib/docker" "@/var/lib/docker")

Here, you can specify a directory or subvolume which will be recursively ignored while scanning for snapshots. The Docker paths are included there by default; it is fine to leave them as they are or delete them if they are not needed, according to your preference.

What you want to do is list out all the root subvolumes (except the one your are booted into) and add them to this line. The root subvolumes are the ones that have been renamed from “@” all the way in the beginning of this topic, in the “Rename the default subvolumes” section. If it helps to see them printed out, run something like this:

sudo btrfs subvolume list / | grep "level 5 "

For example, if I am setting up a multiboot installation and the other installations have root subvolumes named “gnome”, “dr460nized”, “xfce”, “cinnamon”, and “wayfire”, I would set this line up like so:

GRUB_BTRFS_IGNORE_PREFIX_PATH=("var/lib/docker" "gnome" "dr460nized" "xfce" "cinnamon" "wayfire")

(I left one of the Docker directories on there for the example. If you use Docker, you will have to decide what is the appropriate option to use in your case.)

Next, while you are in /etc/default/grub-btrfs/config, there is another line in this file which should be changed:


This is a similar idea, but it is a non-recursive path. Basically it keeps the actual system subvolume from showing up on the snapshot menu. This value should be changed from “@” to whatever you have named the root subvolume.

After you have finished editing the file, run sudo update-grub. Instead of 50 snapshots from all different distros, you should see only snapshots relevant to the system you are booted into.

You will have to set up this file on each installation you have. Optionally, consider setting this file up before setting up /etc/default/grub so when you regenerate the Grub configuration it is not cluttered with extra snapshots right off the bat.

If you add any more installations after /etc/default/grub-btrfs/config has already been set up, you will have to circle back and add the new root subvolume to the IGNORE_PREFIX_PATH list.

Deleting an installation

Deleting an installation is a simple matter of deleting the subvolumes it is contained in. It can be a little tricky in the case of subvolumes that contain read-only subvolumes, such as with snapshots. The main thing to remember is you need to delete the nested subvolumes first in this case.

Subvolumes that do not contain read-only subvolumes can be removed with plain old rm -rf. You will need to elevate, since these subvolumes are owned by root.

:warning: As always, be very cautious when running a command with rm -rf, especially when elevated. You can easily destroy your system by targeting the wrong subvolume or directory.

Read-only subvolumes can be deleted with btrfs subvolume delete–but they cannot be deleted recursively. btrfs subvolume delete does support globbing though, so you can pass a wildcard for the numbered directory and delete them all at once. For example, using xfce as the root subvolume:

sudo btrfs subvolume delete xfce/.snapshots/*/snapshot

With the read-only subvolumes out of the way, you can now delete the top-level subvolume:

sudo rm -rf xfce

All that’s left is to clean up any lingering files on the EFI partition (/boot/efi/EFI/XFCE, for example), and to delete the boot stanza from refind.conf.

You can also use Btrfs Assistant to delete the subvolumes rather easily.

"Show me!"

Deleting the subvolumes in Btrfs Assistant is a simple matter of selecting the subvolumes and clicking on delete! Tick the “Include Timeshift and Snapper Snapshots” box if you would like those to be selectable from the menu as well.

Confirm when the prompt asks whether to delete subvolume metadata.

Subvolumes that contain nested subvolumes will initially fail to delete:


Deleting the nested subvolume will succeed, however, so you may simply re-select the subvolume that failed to delete and try again. In the typical case of a home subvolume (@ in this example) and a Snapper snapshots subvolume (@/.snapshots) it will take three tries to delete all the subvolumes.

Additional considerations

A few worthy considerations that are beyond the scope of this already lengthy topic:


Deduplication is a process which involves identifying data blocks that are identical, but tracked separately, and combining them into an extent. Theoretically, with a multibooting setup like the one described in this topic, deduplication could free up a significant amount of disk space. This should be considered an advanced topic.


This is a tool for easily backing up subvolumes to a separate filesystem–an external drive, for example. Consider making some btrbk backups before you get too in the weeds with deduplication. :wink:

Custom Grub config

The setup described in this topic will work perfectly fine without the rEFInd Boot Manager, however the default Grub configuration will list every installation as “Garuda linux on nvme0n1p2”, “Garuda Linux on nvme0n1p2”, “Garuda LInux on nvme0n1p2”, and so on. This makes it difficult to figure out which installation you want to boot to. If you want a pure Grub setup, it would be useful to make a custom Grub configuration so you can label each boot option however you wish.


Grub is fairly deeply integrated into some of the Garuda tooling, and not easy to remove without losing a lot of other stuff in the process. grub-btrfs is also an incredibly effective and easy-to-use snapshot restoration application. For the purpose of this topic, I have left Grub and grub-btrfs intact for these and other reasons.

However, booting into snapshots from rEFInd itself is also possible thanks to refind-btrfs. It handles snapshots a little differently than grub-btrfs (it maintains its own directory of read-write versions of snapshots for booting into) and lends itself to a different workflow (instead of “restoring” a snapshot and the snapshot automatically becoming the main system, the more obvious use case would be to boot into a snapshot for the purpose of repairing or rolling back the main system manually, then go back and boot to the main system), but it works great and is pretty simple to set up if you already have a manual boot stanza.

Closing thoughts

Hopefully you have found this topic useful or interesting. I am happy to read through questions or corrections in the comments, and don’t forget there is a significantly abridged version of this topic available in the Garuda Wiki here: Multiple installations on one partition | Garuda Linux wiki.




Well done! High marks for accessibility, too.




A wonderful tutorial

Thank you :slight_smile:


bonus points for using refind


What’s that common phrase I’ve been hearing recently? Just because you can do something doesn’t mean you should lol


Gosh... top tenacity.
Speechless. :no_mouth: :+1:


Because I don’t know. I went down this exact rabbit hole, checks date before dalto, on bare metal and I still don’t know why I didn’t just blow up the unused distros at that time.

1 Like

It seems to be a rite-of-passage for some folks.


How much time did you take you write the guide itself?

Hats off @BluishHumility!


Honestly I hadn't initially set out to create a document--rather, I had been putting together notes in Joplin while figuring out the process for myself. I have been trying to get into the habit of documenting how I set things up when I am doing something new or different. For certain things, I have found good documentation can be more valuable than a backup.

At some point, I ended up referring to the notes for a solution here in the forum (this one), and someone on the team mentioned it might be handy if I could write up a guide and put it in the wiki. The wiki post was honestly a piece of cake to write, because I just added some explanatory sentences to the notes I already had.

When we started getting close to the Raptor release, I thought it would be fun (and/or funny) to install every Raptor spin with this method, and I decided to write a topic to accompany the wiki post. That is when I had to put some effort into it, because multibooting so many installations without using the rEFInd Boot Manager would be...well, less awesome. :wink:

So I had to double-back and put together some notes for how to get rEFInd set up. As you can see, those notes ended up being more lengthy than all the subvolume setup! :joy:

In the end, it did end up taking a while to put together--at least a few hours. And although the whole project was done somewhat tongue-in-cheek (I have turned something practical or useful into a novelty, or even an absurdity), I do hope it can be a useful reference for folks who would like to get started using rEFInd or multibooting with subvolumes.


Yay! Another Joplin user!


Joplin is amazing! And it's in the Chaotic-AUR!

pacman -Ss joplin
chaotic-aur/joplin-beta-appimage 2.10.11-1 [installed]
    The latest beta AppImage of Joplin - a cross-platform note taking and to-do app

Actually for all these recent installations I did, Joplin was the only app I pulled in from the Setup Assistant.

Then I would enable dark mode (obviously :sunglasses:) and sync to my Nextcloud, and once it's up I have a full list of the base packages I install and some configs I set up that I can just copy/paste over.

Once Joplin is synced it takes like five or ten minutes for a fresh installation to be fully set up how I like it--aside from proper ricing, of course. :wink:


5 posts were split to a new topic: Custom Joplin Icon

I recently made some time to sit down and revisit the topic of deduplication, and figured I would launch a system-wide dedupe targeted at this mostrosity of a filesystem I have created because: why not?

Out of the various tools available to assist with deduplication, BEES and Duperemove seem to stand out, and are even mentioned explicitly in the Btrfs documentation here. They are somewhat different in how they operate; BEES operates on the block level, while Duperemove operates on the file level. Additionally, BEES is intended to run in a sort of daemon-mode, constantly churning away in the background, while it seems Duperemove is better suited for the occasional one-off effort.

The latter of those points initially compelled me to give Duperemove a shot for this purpose, as I was primarily just curious what would happen. The clincher ended up being this note from the BEES documentation:

“If a subvol is deduped after many snapshots have been created, all subvols must be deduplicated individually. In the worst case, this will multiply the scanning work and metadata size by the number of snapshots. For 100 snapshots this can mean a 100x growth in metadata size and bees scanning time, which typically exceeds the possible savings from reducing the data size by dedupe. In such cases using bees will result in a net increase in disk space usage that persists until the snapshots are deleted.”"

Yikes! That description definitely applies to this system, as it has been up for a while already and many, many snapshots already exist in the filesystem–if not 100, then probably close to it. It seems like it would be a disappointment to run a full-system dedupe only to wind up losing disk space.

It should be noted this particular “gotcha” would resolve over time on its own, as old snapshots are turned over and the new snapshots would be incorporated into BEES dedupe process. Still, for this test I just wanted to run it and see what happened, so ultimately BEES seemed like it was a bit overkill.

How to calculate what space savings is achieved? From the Duperemove FAQ (see also man duperemove):

How can I find out my space savings after a dedupe?

Duperemove will print out an estimate of the saved space after a dedupe operation for you.

You can get a more accurate picture by running ‘btrfs fi df’ before and after each duperemove run.

First, I’ll take a look at filesystem usage before running Duperemove:

btrfs fi df /
Data, single: total=164.01GiB, used=163.16GiB
System, DUP: total=32.00MiB, used=48.00KiB
Metadata, DUP: total=8.00GiB, used=7.51GiB
GlobalReserve, single: total=501.31MiB, used=0.00B

Run the process, targeting the root of the filesystem:

sudo duperemove -dhr /

In my case, it took about twenty minutes to run. Then, it spits out this little summary at the end:

Comparison of extent info shows a net change in shared extents of: 25.9G

Almost 26 GB, wow!

Now to check btrfs fi df /:

btrfs fi df /
Data, single: total=164.01GiB, used=141.49GiB
System, DUP: total=32.00MiB, used=48.00KiB
Metadata, DUP: total=10.00GiB, used=8.68GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

Useage before: 163.16+7.51=170.67 GiB
Useage after: 141.49+8.68=150.17 GiB

20.5 GiB, or just over 22 GB. A few GB less than Duperemove estimated, but still a substantial space savings–about 13% of the used disk space has been freed up.

Now I guess have to poke around a bit and find out if I broke anything! :man_detective:


I went for duperemove once, at some point it just used too much ram and got killed by systemd-oomd :joy: I'm assuming that's due to the amount of snapshots haha. nevertheless, very cool that this is actually possible ! :grin:


Can I inquire about this. :eyes: Did anything break? Like missing actually important files/loss of personal data? I have been eyeing this topic for a while and recently my interest in exploring an alternative to grub and using i3wm has flared (I just wanna try it out for the possibility of being able to implement vim motions outside vim :stuck_out_tongue_winking_eye: ). I went through the thread and wanted to know if this (dedupe) was a good idea in the long run?

1 Like

No issues whatsoever! It worked fine and nothing ever broke that I am aware of. Some of those installations have been retired since March, but the ones that are still up are perfectly fine. No missing files to speak of.

I think with thirteen installations of Garuda Linux all on the same filesystem, I probably had a lot of duplicate files that were able to be consolidated (from packages or libraries that were installed on multiple or all of the systems, etc). That is to say, I’m not sure the space savings would be quite as significant on a more “normal” setup. But I am not sure, so give it a shot and let me know!

Of course, make backups before running a deduplication process on important data! If you need motivation, here is a recent example from the forum where things went wrong with deduplication and important data was lost: Deleted_My_Files_Accidentally


i keep my most important files in multiple locations and on multiple ssd devices just in case.


That’s a good system. SSD multi-TB drives are so cheap right now they don’t make a person feel like they’re “puttin’ a $100 saddle on a $50 nag” even with some older rigs. :wink:

The hard part if figuring out what to rsync where & when.