Uploaded image for project: 'StoRM'
  1. StoRM
  2. STOR-1561

CREATE date in the future in table storage_space

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Fixed
    • Icon: Critical Critical
    • 1.11.22
    • 1.11.21
    • backend
    • Security Level: Public (Visbile by non-authn users.)
    • None

      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

            vianello Enrico Vianello
            lmorganti Lucia Morganti
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: