BTRFS: Delete attribute "parent_uuid" possible?

Ask Fedora
, ,
1

Hi community,

today i’m facing a more cosmetical issue that i would like to get rid of. It’s the BTRFS subvol parent UUID, that flags a subvol as snapshot.

a workaround would be to set the subvol ro, send them to a file, delete the source subvol, receive them back to its original location and make the subvol rw again, as you can see in my screenshot, have a look at the root and home subvol:

image
image1236×660 82.9 KB

i think, it’s all about the parent UUID. but i couldn’t find a way to delete them without the time-consuming send/receive proccess.

any help would be greatly appreciated. Thanks in advance.

2

btrfs receive will set a parent UUID too, because a send stream is a subvolume snapshot, therefore receiving it creates a subvolume snapshot. Send+Receive replicates subvolume snapshots.

You can btrfs sub create and then cp -a the files from old to new, as if it were a directory.

But why?

3

Hi @chrismurphy, thanks for your reply.

as i’m not good in explaining, i’ll try it with some screenshot, hope, that is ok.

I think, you are wrong. BTRFS Receive does the opposite - it removes the parent ID - see for yourself:

image
image898×677 64.3 KB

feel free to test this in a vm.

Out of curiosity, if i remove a parent subvol, shouldn’t the parent UUID be removed from it’s child, because no parent exists anymore, as shown in this example:

image
image706×296 33.6 KB

as you can see, the Parent UUID still exist, but the parent doesn’t exist anymore. This leads to misinformation.

Maybe it’s my ADHD, but the above just feels wrong to me…

i believe, that makes no sense and defeats the purpose of BTRFS/Subvols. i won’t do that.

i usualy do send/receive to transfer my whole silverblue installation from one bare metal to another…

4

“A snapshot is simply a subvolume that shares its data (and metadata) with some other subvolume, using Btrfs’s COW capabilities.” (btrfs wiki)

Any subvolume (i. non-top volume) will have a Parent ID different from 0.
Snapshots will also have a Parent UUID which indicates which subvolume it shares data (and metadata) with. (I’ll not comment further on whether that naming is helpful…)

Whether send/receive removes parent UUIDs depends on your use of options, in particular -p. For example, in a typical backup use case I have a snapshot on the sending side (using -p):

        Name:                   2024-09-20T17:42+02:00
        UUID:                   a85464f2-dca4-f44e-ae74-b5311cb008f3
        Parent UUID:            fa20ddb8-809f-4e49-a77a-7d87639c6147
        Received UUID:          -

And a snapshot on the receiving side:

        Name:                   2024-09-20T17:42+02:00
        UUID:                   dad8eb13-d92d-ea41-871a-3bec1c54fcee
        Parent UUID:            71c822cb-8b84-4947-b47b-dc4fbf386498
        Received UUID:          a85464f2-dca4-f44e-ae74-b5311cb008f3

IDs of both have no relation (they are subvolumes of different top level volumes of different btrfs file systems on different machines).
By using -p, I allow send to send only what is not shared with the parent already, and this assumes that that parent is present on the receiving side.

sending without -p send the whole subvolume and - consequently - removes that Parent UUID.

Now, if you remove such a parent, I would think that the extents (data, metadata) are still present in the file system. I don’t know whether clean or scrub clean up the stale Parent UUID reference, though.

5

I think, you are wrong. BTRFS Receive does the opposite - it removes the parent ID - see for yourself:

The parent ID becomes the received UUID.

But if you use the property to unset ro flag, the received UUID is removed because unsetting ro invalidates the snapshot for incremental send/receive as a safety precaution.

Shouldn’t the parent UUID be removed from it’s child, because no parent exists anymore

Why should it?

The deletion of the parent doesn’t change the fact the child is derived from the parent subvolume. Subvolume snapshots are prefilled subvolumes, at the time they’re created they’re filled with data from another subvolume. Deleting the original doesn’t change that fact.

I’m personally not a fan of removing metadata from anything. I want as much of it tracking things as possible. We sometimes see folks remove metadata and then regret it later, not realizing it comes in handy - e.g. using property to remove the ro flag, and thereby breaking incremental send/receive for their snapshots.

Anyway, I think trying to remove it is unnecessary effort. And using send-receive to do it just doubles the write wear on your media.