Package: dirvish
Version: 1.2.1-2.1
Severity: normal
X-Debbugs-Cc: [email protected]
Dear Maintainer,
It looks like the sort order in sub imsort() at the end of
dirvish-expire.pl despite the comment makes it remove the newest images
in case all good images are expired.
When all good images are expired no image will set $unexpired{} during
findop().
Then imsort() order the images by increasing creation time, and thus the
oldest images are handled first during the removal loop
for $expire (sort {imsort()} @expires)
Note: in upstream, that is (I've tried both, same result)
for $expire (sort(imsort @expires))
Therefore the oldest image is not deleted (No unexpired good images) and
sets $unexpired{}. Then it proceeds by removing all newer images, since
$unexpired{} is set.
My situation:
Image Expire Status
20220731_0457 2022-08-28 04:57:30 success
20221113_1745 2022-11-16 17:45:19 incomplete (empty creation date)
20221119_0901 2022-11-22 09:01:09 incomplete (not expired)
20221119_1745 2022-11-20 17:45:27 success
When I run 'dirvish-expire --no-run' it suggests the following:
"
Expiring images as of 2022-11-20 23:01:56
VAULT:BRANCH IMAGE CREATED EXPIRED
cannot expire nr_data1:default:20221113_1745 No unexpired good images
cannot expire nr_data1:default:20220731_0457 No unexpired good images
nr_data1:default 20221119_1745 2022-11-20 21:35 +3 days == 2022-11-20 17:45
"
I.e. it would delete the new good image and keep the old.
If the creation data sort order is reversed from
|| $$a{created} cmp $$b{created};
to
|| $$b{created} cmp $$a{created};
I get:
"
VAULT:BRANCH IMAGE CREATED EXPIRED
cannot expire nr_data1:default:20221119_1745 No unexpired good images
nr_data1:default 20220731_0457 2022-07-31 05:07 +28 days == 2022-08-28 04:57
nr_data1:default 20221113_1745 +3 days == 2022-11-16 17:45
"
The warning just above imsort() of course makes me a bit worried if I am
right:
## WARNING: don't mess with the sort order, it is needed so that if
## WARNING: all images are expired the newest will be retained.
but the system has now repeatedly removed some new good copies. Reason
it ended up doing this is that the backup takes more time than the
expiration period of the new images. It was also offline for a while,
explaining the long times and rather old data of the previous good image.
(Note: the issue was also reported upstream
https://lists.dirvish.org/pipermail/dirvish/2022-November/003354.html
which I guess was reporting in the wrong order.)
Best regards,
Håkan
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-19-cloud-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dirvish depends on:
ii libtime-parsedate-perl 2015.103-3
ii libtime-period-perl 1.25-1
ii perl 5.32.1-4+deb11u2
ii rsync 3.2.3-4+deb11u1
Versions of packages dirvish recommends:
ii ssh 1:8.4p1-5+deb11u1
dirvish suggests no packages.
-- Configuration Files:
/etc/cron.d/dirvish changed [not included]
/etc/dirvish/dirvish-cronjob changed [not included]
-- no debconf information
