Hi,
we have a major issue with storm backend.
We notice most storage areas in storage_space table in storm_be_ISAM db have "CREATED" date in the future:
MariaDB [storm_be_ISAM]> select ALIAS, CREATED, UPDATE_TIME from storage_space;
------------------------------------------------------------
ALIAS | CREATED | UPDATE_TIME |
------------------------------------------------------------
SCRATCH_TOKEN | 2022-07-19 04:48:29 | 2022-07-18 16:59:22 |
CTALST_TOKEN | 2022-07-19 08:43:26 | 2022-07-18 16:59:22 |
VIRGO4_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:59:22 |
ICARUSEXPORG_TOKEN | 2022-07-19 08:43:26 | 2022-07-18 16:59:22 |
ICARUSPLAIN_TOKEN | 2022-07-19 04:44:35 | 2022-07-18 16:59:22 |
ARGO_TOKEN | 2022-07-19 08:43:26 | 2022-07-18 16:57:21 |
PADME_TOKEN | 2022-07-19 04:44:35 | 2022-07-18 16:59:22 |
DTEAMDATA_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:59:22 |
VIRGO5_TOKEN | 2022-06-08 18:19:54 | 2022-07-14 21:30:37 |
CTALSTTAPE_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:59:22 |
BELLEDATA_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:59:22 |
AMS_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:59:50 |
VIRGOPLAIN_TOKEN | 2022-06-08 18:19:54 | 2022-06-08 16:19:54 |
PAMELA_TOKEN | 2022-07-19 08:43:26 | 2022-07-18 16:59:22 |
JUNO_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:59:22 |
OPS_TOKEN | 2038-01-19 03:19:54 | 2022-07-18 16:56:27 |
AUGERTAPE_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:59:22 |
DTEAMARCHIVE_TOKEN | 2022-07-19 08:43:25 | 2022-07-18 16:57:21 |
AGATA_TOKEN | 2022-07-19 10:43:26 | 2022-07-18 16:59:22 |
CTA_TOKEN | 2022-07-19 10:43:25 | 2022-07-18 16:59:22 |
KM3NET_TOKEN | 2022-07-19 08:43:25 | 2022-07-18 16:59:22 |
GERDAMPGDE_TOKEN | 2022-07-19 10:43:25 | 2022-07-18 16:59:22 |
CTADISK_TOKEN | 2022-07-19 10:43:25 | 2022-07-18 16:59:22 |
NA62_TOKEN | 2022-07-19 10:43:25 | 2022-07-18 16:59:22 |
MUONCOLL_TOKEN | 2022-07-19 06:44:35 | 2022-07-18 16:59:22 |
INFO_TOKEN | 2022-06-08 18:19:54 | 2022-06-08 16:19:54 |
BELLE_TAPE | 2022-07-19 10:43:25 | 2022-07-18 16:59:22 |
ILDG_TOKEN | 2022-07-19 04:44:35 | 2022-07-18 16:59:22 |
GLASTORG_TOKEN | 2022-07-19 08:43:25 | 2022-07-18 16:57:21 |
GERDAMPGDEDISK_TOKEN | 2022-07-19 08:43:26 | 2022-07-18 16:59:22 |
DAMPETAPE_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:59:22 |
BELLE | 2022-07-19 10:43:25 | 2022-07-18 16:59:22 |
PROCDATA_TOKEN | 2022-06-08 18:19:54 | 2022-06-08 16:19:54 |
DTEAMVIRGO4_TOKEN | 2022-07-19 04:48:29 | 2022-07-18 16:59:22 |
DARKSIDETAPE_TOKEN | 2028-10-08 05:19:54 | 2022-07-18 16:57:21 |
THEOPHYS_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:57:21 |
PADMETAPE_TOKEN | 2022-07-19 06:43:26 | 2022-07-18 16:57:21 |
BELLETMP_TOKEN | 2022-07-19 08:43:26 | 2022-07-18 16:59:29 |
XENONTAPE | 2022-07-18 16:43:26 | 2022-07-18 16:43:26 |
AUGER_TOKEN | 2022-07-19 10:43:25 | 2022-07-18 16:59:22 |
ICARUSDATA_TOKEN | 2022-07-19 02:48:29 | 2022-07-18 16:59:22 |
XENONDISK | 2022-07-19 04:48:29 | 2022-07-18 16:59:22 |
------------------------------------------------------------
42 rows in set (0.00 sec)
Deleting rows doesn't solve the issue, as the backend seems to recreate them with wrong date after a while.
Such future creation dates prevent a correct update of space information in the DB, so that some experiments have started getting "No free space" errors even if there actually is space.
I am pretty sure a similar bug was already investigated in the past but cannot find the issue.
Thanks for checking,
lucia