2

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:          -
    Snapshot(s):
                snap_before_sid
George Shuklin
  • 591
  • 1
  • 5
  • 9
  • Please see [this answer](https://superuser.com/a/1396270/432690). 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. – Kamil Maciorowski Feb 26 '23 at 07:27
  • ...also this [link](https://unix.stackexchange.com/q/491589/352872) will be useful. – xUr Feb 27 '23 at 01:26

1 Answers1

0

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.

BUT:

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.

xUr
  • 213
  • 2
  • 7
  • 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). – George Shuklin Feb 25 '23 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 '23 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). – George Shuklin Feb 25 '23 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 '23 at 01:40