Detect ZFS snapshot name collision, append unique identifier #2

New Issue

2023-09-03T16:29:19Z

hygienic-books commented

2023-09-03 16:29:19 +00:00

Current implementation in branch "1-get-base-version-going" will happily try to create a ZFS snapshot with the exact same name as a prior one:

Do the exact same operation (such as pacman -S package) twice for example when installing or reinstalling a package
Make sure this happens within whatever timestamp format is set. pacman-zfs-snapshot.conf defaults to snap_date_format='%F-%H%M' where snapshots take this form:
```
zpool/root/archlinux-frn@pacman_2023-09-03-1413_op:upgr_sev:trv_pkgs:proton-ge-custom-bin
zpool/root/archlinux-frn@pacman_2023-09-03-1413_op:upgr_sev:trv_pkgs:ttf-mplus-git
                                ~~~~~~~~~~~~~~~
```
Two installations (or reinstallations) for example within the same minute done for the same set of packages will cause a ZFS snapshot name collission and uncleanly fail.

Add option to include a unique identifier in snapshot names for example like so:

```
zpool/root/archlinux-frn@pacman_2023-09-03-1413_1_op:upgr_sev:trv_pkgs:proton-ge-custom-bin
zpool/root/archlinux-frn@pacman_2023-09-03-1413_1_op:upgr_sev:trv_pkgs:ttf-mplus-git
                                               ~~
```

This should

Start at 1
Monotonically increase by 1 for each consecutive snapshot that otherwise would cause a naming collision
Be toggle-able via config file setting (do or do not append _1, _2 etc.)
Adhere to snap_field_separator setting which defaults to the underscore character (_) via snap_field_separator='_'
Default to being enabled
Come with a written warning both in pacman-zfs-snapshot.conf and our main README.md that when this gets toggled off and a naming collision does happen because of it the snapshot will not be done and instead any ongoing pacman transaction will abort
Come with a clause that catches naming collisions and before exiting 1 informs the users on stdout that their pacman action is getting canceled because of the collision and how to fix this.
Come with updated example output of zfs list in README.md that shows the suffix in action.

Current implementation in [branch "1-get-base-version-going"](https://quico.space/quico-os-setup/zfs-pacman-hook/src/branch/1-get-base-version-going) will happily try to create a ZFS snapshot with the exact same name as a prior one: - Do the exact same operation (such as `pacman -S package`) twice for example when installing or reinstalling a package - Make sure this happens within whatever timestamp format is set. [pacman-zfs-snapshot.conf](https://quico.space/quico-os-setup/zfs-pacman-hook/src/branch/1-get-base-version-going/pacman-zfs-snapshot.conf) defaults to `snap_date_format='%F-%H%M'` where snapshots take this form: ``` zpool/root/archlinux-frn@pacman_2023-09-03-1413_op:upgr_sev:trv_pkgs:proton-ge-custom-bin zpool/root/archlinux-frn@pacman_2023-09-03-1413_op:upgr_sev:trv_pkgs:ttf-mplus-git ~~~~~~~~~~~~~~~ ``` Two installations (or reinstallations) for example within the same minute done for the same set of packages will cause a ZFS snapshot name collission and uncleanly fail. Add option to include a unique identifier in snapshot names for example like so: ``` zpool/root/archlinux-frn@pacman_2023-09-03-1413_1_op:upgr_sev:trv_pkgs:proton-ge-custom-bin zpool/root/archlinux-frn@pacman_2023-09-03-1413_1_op:upgr_sev:trv_pkgs:ttf-mplus-git ~~ ``` This should - Start at 1 - Monotonically increase by 1 for each consecutive snapshot that otherwise would cause a naming collision - Be toggle-able via config file setting (do or do not append `_1`, `_2` etc.) - Adhere to `snap_field_separator` setting which defaults to the underscore character (`_`) via `snap_field_separator='_'` - Default to being enabled - Come with a written warning both in `pacman-zfs-snapshot.conf` and our main `README.md` that when this gets toggled off and a naming collision does happen because of it the snapshot will not be done and instead any ongoing `pacman` transaction will abort - Come with a clause that catches naming collisions and before exiting 1 informs the users on stdout that their `pacman` action is getting canceled because of the collision and how to fix this. - Come with updated example output of `zfs list` in [README.md](README.md) that shows the suffix in action.

hygienic-books commented

2023-12-25 23:13:54 +00:00

Won't fix. Thought about this and decided that simply skipping these otherwise identical snapshots is more straightforward.

The rationale is that user's doing the exact same operation twice or more. There's most likely no reasonable expectaion that their operating system enters a different state on successive pacman operations so there's no need to deal with multiple snapshots capturing the same state.

Won't fix. Thought about this and decided that simply skipping these otherwise identical snapshots is more straightforward. The rationale is that user's doing the exact same operation twice or more. There's most likely no reasonable expectaion that their operating system enters a different state on successive `pacman` operations so there's no need to deal with multiple snapshots capturing the same state.

hygienic-books closed this issue

2023-12-25 23:13:54 +00:00

hygienic-books commented

2023-12-26 05:10:51 +00:00