I have a root filesystem on btrfs. A long time ago I've created snapshot (snap_before_sid). I done bad things with my system and switched to this snapshot (btrfs filesystem set-default snap_before_sid). Everything is looking nice and working, but I'm worried about 'lost space' due to old top-level subvolume (id 5) somewhere there.

Is there any way to:

  1. Either remove id 5 subvolume?
  2. Or to merge current snapshot (current default subvolume) to it and remove it.
  3. Or to purge used space by id5 subvolume?

My fs looks like this:

btrfs subvolume list  / -a -p 
ID 276 gen 311412 parent 5 top level 5 path <FS_TREE>/snap_before_sid
btrfs subvolume show  -r 5 /
    Name:           <FS_TREE>
    UUID:           -
    Parent UUID:        -
    Received UUID:      -
    Creation time:      -
    Subvolume ID:       5
    Generation:         311399
    Gen at creation:    0
    Parent ID:      0
    Top level ID:       0
    Flags:          -
  • Please see this answer. Maybe you're not using @, it doesn't matter. What matters is you can mount the root of the Btrfs tree elsewhere and manage the whole filesystem from there. This includes removing arbitrary files from any subvolume with rm or whatever. Feb 26, 2023 at 7:27
  • ...also this link will be useful.
    – xUr
    Feb 27, 2023 at 1:26

1 Answer 1


I'm not a profi in BTRFS. I've been using it for a few weeks. Also I have to say that I know this case theoretically I did not do the tests but I have some idea of your questions.

  1. Either remove id 5 subvolume?

As far as I understand, BTRFS cannot delete the root subvolume.

  1. Or to merge current snapshot (current default subvolume) to it and remove it.

As far as I understand BTRFS does not know how to merge snapshots. It does not have this functionality.


A snapshot is a subvolume like any other, with given initial content. By default, snapshots are created read-write. File modifications in a snapshot do not affect the files in the original subvolume.

See link.

I understand that a snapshot is a subvolume and it has all the features of a subvolume, but as we can see, it is marked as a snapshot. So it's not quite subvolume. :)

You change the default subvolume and thus you get a "merge". This is one of the right cases.

Another case:

EDITED: !!!WARNING!!! In your case, when you mount the root volume (subvolume), you may see the snapshot directory (or snapshot subvolume), be careful with sync, it may remove all files. I'm not sure if we can remove the snapshot volume as a snapshot directory, and I won't try to check that on a workstation. :) I would sync the files without the snapshot directory (or snapshot subvolume) and don't use mirror sync and use custom sync.

Have a subvolume and snapshot. To restore data from a snapshot, you can use a sync application (like rsync or I use FreeFileSync, I like the GUI) which can sync files like a mirror. In this case, you can have the restored subvolume and delete the snapshot. And go to drink tea or coffee.

See Recovering Files from Snapshots link.

How you can change your case to Another case? (EDITED)

I had a test. And I reverted root volume back as the default.

You did btrfs filesystem set-default snap_before_sid [path] it is the same of btrfs filesystem set-default 276 [path]. 276 - id of your snap_before_sid

And then you can do btrfs filesystem set-default 5 [path]. 5 - id of your <FS_TREE> i.e. root volume.

After that you can check default volume - btrfs subvolume get-default [path]. You should get an answer - ID 5 (FS_TREE).

Don't remember remount BTRFS again. You will see the root volume revert back.

The root volume is not lost forever. It will make the top level of the filesystem inaccessible until you revert root volume back as default. It is temporarily hidden.

And after that you can go to the Another case step and play around with rsync.

See link.

  1. Or to purge used space by id5 subvolume?

Sorry, I don't know. But I think BTRFS can not do this.

I hope my answer will help you.

  • Thanks. So, it's not possible. Unfortunately, it looks like switching from root to snapshot for root filesystem in case of 'broken upgrade' is not a best practice (to say politely). Feb 25, 2023 at 11:28
  • @GeorgeShuklin If it's not a secret. Why do you think so? Do you found the solution at your case?
    – xUr
    Feb 25, 2023 at 12:31
  • I think so because I failed to find a solution, and your answer is confirming that switching to snapshot as a default subvolume leaves original root volume locked (you can't free space from it, you can't remove it). Feb 25, 2023 at 18:36
  • @GeorgeShuklin I sincerely want to help you and understand your problem, since I am deciding now whether I will use BTRFS and what problems I'll have with BTRFS in future. I edit post. The root volume is not lost forever. It is temporarily hidden.
    – xUr
    Feb 26, 2023 at 1:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .