List btrfs snapshots separately in the subvolume detail page

[jelly]

This PR identifies snapshots and lists them under the subvolume in a separate card.

Open questions:

• Should we have actions on snapshots when they are listed in the crossrefs table? At least "Delete" seems appropriate.
• In the detail view, we now list snapshots and subvolumes both, We should probably hide snapshots from the subvolume list?
• Do we show snapshots are "btrfs snapshot" instead of "btrfs subvolume".

---

Show snapshots of a subvolume in the detail view

Snapshot origin is shown in snapshot detail view

[jelly]

@mvollmer I thought a bit on how we could implement filtering:

We could come up with a system where we don't have to hardcode the "filters" in but we could register filters for pages which want that.

register_filter(display_name, property_name)

This registers a filter which lives in pages.jsx, then we use these filter with property_name and filter_properties.

Alternatively, we just hardcode filters:

PAGE_FILTER_SNAPSHOT = 'snapshot'

Page/Card can have filter_properties which contains the key we are interested for with the value. State can come later.

I'm not thinking of introducing something like a filter component. But maybe it is interesting to have something usable.

[mvollmer]

@mvollmer I thought a bit on how we could implement filtering:

I think this is a bit too much machinery. Let's just do what we need, and nothing more.

[jelly]

Alright, after the discussion today in standup:

• First pass, show snapshots under a subvolume
• Second pass, hide snapshots

[jelly]

@garrett question from @mvollmer did we decide on the design yet?

So my idea is:

• Hide snapshots on the overview
• List snapshots of a subvolume in the subvolume detail page.

[garrett]

@jelly: Yes, I think that's what we want. Good, simple summary.

I think we (you and/or @mvollmer and I) agreed on that a while ago somewhere? Perhaps in a video call? Perhaps in an issue? I don't remember where, but if we all agree on that, then that's great.

To restart: I definitely do not want them on the overview (and never have) and I think the details pages are the right places for the snapshots.

[mvollmer]

So the listing of snapshots on the page of their origin in a crossref table works. Let's nail down when to hide snapshots in the regular child tables.

What about this: snapshots are only included in a child table when they are on the top-level. Otherwise they are replaced with a row that summarizes them "(20 snapshots)". Clicking on that row will go to the parent of those snapshots.

Here is a made-up example (without that rule applied):

Here, all the home-123 and images-123 subvolumes are snapshots. They would be omitted from the table and replaced with "(13 snapshots)".

But when going to the "snapshots" subvolume, they would be listed like they are now, because they are on the top-level in that table:

And of course they would also be listed on the page of their origin:

In addition the page for a snapshot subvolume should have a link back to its origin:

Heere the could be a description row with "Snapshot origin data/home".

[jelly]

So the listing of snapshots on the page of their origin in a crossref table works. Let's nail down when to hide snapshots in the regular child tables.

Good point.... I forgot about that...

So on the overview they need to go away, that is a requirement from @garrett

What about this: snapshots are only included in a child table when they are on the top-level. Otherwise they are replaced with a row that summarizes them "(20 snapshots)". Clicking on that row will go to the parent of those snapshots.

What view is this? The filesystem detail page? Can we differentiate the overview and filesystem detail page easily?

Here is a made-up example (without that rule applied):

Here, all the home-123 and images-123 subvolumes are snapshots. They would be omitted from the table and replaced with "(13 snapshots)".

Hmm feels a bit magical to me.

But when going to the "snapshots" subvolume, they would be listed like they are now, because they are on the top-level in that table:

But then you wouldn't know it is a special subvolume would you? Better asked, how would we implement this:

for subvolume in parent_dir.subvolumes:
       if subvolume.parent__uid == parent_dir.uuid
            show()
      else
           hide()

The problem is a bit that BTRFS is very lenient and you can make everything everywhere without having to give it logical names.

And of course they would also be listed on the page of their origin:

Agreed.

In addition the page for a snapshot subvolume should have a link back to its origin:

Heere the could be a description row with "Snapshot origin data/home".

Stretch goal, but seems nice!

[mvollmer]

Better asked, how would we implement this:

for subvolume in parent_dir.subvolumes:
       if subvolume.parent__uid == parent_dir.uuid
            show()
      else
           hide()

So parent_uuid is the origin of the snaphot subvolume, and parent_dir is the parent subvolume, right? In my example, "snapshots" is the parent of "home-1234", and "home" is the origin of "home-1234" (since it was created by "btrfs subvolume snapshot /run/butter/data/home /run/butter/data/snapshots/home-1234").

So your code above would not hide any snapshots in my example, since no snapshot subvolume has the subvolume as both parent and origin. It would only hide snapshots that are directly inside their origins, like the one created by "btrfs subvolume snapshot /run/butter/data/home /run/butter/data/home/snapshot-1".

In my understanding, we want to get rid of snapshots in our tables because there are too many of them and they are usually not interesting. Isn't that the goal?

[mvollmer]

What about this: snapshots are only included in a child table when they are on the top-level. Otherwise they are replaced with a row that summarizes them "(20 snapshots)". Clicking on that row will go to the parent of those snapshots.

What view is this? The filesystem detail page? Can we differentiate the overview and filesystem detail page easily?

That rule would apply to any ChildrenTable, thus to each page, overview and details.

We can distinguish overview and details pages and we do that already: only the overview has icons, for example), But I propose we don't do that when deciding whether to hide snapshots. If they are distracting on the overview, they are also distracting elsewhere, no? And with the summary line, you can easily find the place that lists them all.

[mvollmer]

Should we have actions on snapshots when they are listed in the crossrefs table? At least "Delete" seems appropriate.

[jelly]

Better asked, how would we implement this:

for subvolume in parent_dir.subvolumes:
       if subvolume.parent__uid == parent_dir.uuid
            show()
      else
           hide()

So parent_uuid is the origin of the snaphot subvolume, and parent_dir is the parent subvolume, right? In my example, "snapshots" is the parent of "home-1234", and "home" is the origin of "home-1234" (since it was created by "btrfs subvolume snapshot /run/butter/data/home /run/butter/data/snapshots/home-1234").

So your code above would not hide any snapshots in my example, since no snapshot subvolume has the subvolume as both parent and origin. It would only hide snapshots that are directly inside their origins, like the one created by "btrfs subvolume snapshot /run/butter/data/home /run/butter/data/home/snapshot-1".

No this does indeed not work...

[root@fedora-40-127-0-0-2-2201 ~]# btrfs subvolume list -apuq /
ID 256 gen 838 parent 5 top level 5 parent_uuid -                                    uuid 13c51cda-d57a-0a45-a808-1785eca3bc28 path <FS_TREE>/root
ID 257 gen 838 parent 5 top level 5 parent_uuid -                                    uuid 9d64752d-1de6-2849-baac-696ce79f3a7b path <FS_TREE>/home
ID 258 gen 840 parent 5 top level 5 parent_uuid -                                    uuid bd3edcf1-e9b5-654a-96ec-6e62ee17d924 path <FS_TREE>/var
ID 259 gen 78 parent 258 top level 258 parent_uuid -                                    uuid b3735d93-91e0-1046-98f7-e377fafc1b3c path <FS_TREE>/var/lib/machines
ID 260 gen 836 parent 256 top level 256 parent_uuid -                                    uuid 6b5445f7-2d40-5c45-b914-9eedd47dd5cd path root/snapshots
ID 261 gen 836 parent 260 top level 260 parent_uuid 9d64752d-1de6-2849-baac-696ce79f3a7b uuid cf9b06e1-6141-0b42-b61c-5d2c920e88ab path <FS_TREE>/root/snapshots/today

In my understanding, we want to get rid of snapshots in our tables because there are too many of them and they are usually not interesting. Isn't that the goal?

Yes, but you argued for showing them?

[jelly]

Should we have actions on snapshots when they are listed in the crossrefs table? At least "Delete" seems appropriate.

Sounds reasonable.

[mvollmer]

In my understanding, we want to get rid of snapshots in our tables because there are too many of them and they are usually not interesting. Isn't that the goal?

Yes, but you argued for showing them?

Yes, but sparingly. Snapshots are also subvolumes and we need to offer all the functionality of subvolumes for them, somewhere. Maybe people want to mount them, or copy them back to their origin.

[jelly]

Some conclusions from my side:

• We want to hide snapshots from the overview (or allow filtering) as it gets too cluttered
• Show snapshots underneath a subvolume where all snapshots live makes a lot of sense, otherwise I would have to know that the snapshots from my home partition in the UI are shown in that subvolume. This makes it tricky as we want something different for the overview

Note: what if we show a subvolume snapshot as btrfs snapshot instead of btrfs subvolume.

[jelly]

Conclusion from standup with @mvollmer "Let's merge this and figure out filtering/hiding subvolumes later.

[jelly]

@martinpitt do you mind taking the review over?

[jelly]

Alternative idea, we have one list of subvolumes:

• Show subvolumes and snapshots different, either with a Label
• Allow filtering of the table

[mvollmer]

This should be a link, no?

[mvollmer]

Let's add the "Delete" action here.

[mvollmer]

Thanks!

[cockpituous]

This added line is not executed by any test.