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