Full spacetoken size automatically increased with HTTP-TPC

[vokac]

When spacetoken gets full

[root@se1 ~]# date; ssh -p 22224 -l admin localhost '\c SrmSpaceManager; ls spaces -e' | grep ATLASLOCALGROUPDISK
Fri Aug 21 04:00:08 AM CEST 2026
TOKEN LINKGROUP                         RETENTION LATENCY      ALLO               USED              FREE               SIZE             EXPIRES DESCRIPTION
 3    spacemanager_linkGroup_heppool1   REPLICA   ONLINE         60 +  571777946956975 +               0 =  571777946957035                     ATLASLOCALGROUPDISK

it is not longer possible to upload additional data

$ gfal-copy /tmp/10G https://se1.farm.particle.cz/atlas/atlaslocalgroupdisk/SAM/10G
Copying file:///tmp/10G   [FAILED]  after 0s
gfal-copy error: 256 (Unknown error 256) - TRANSFER ERROR: Copy failed (streamed). Last attempt: HTTP 500 : Unexpected server error: 500  (destination)

with not so clear error message but billing log provides sufficient details

08.21 04:02:06 [door:WebDAV-se1@doorsDomain:request] ["atlas_production":3003:3003:2001:718:401:6025:10:0:0:1] [0000603E11E936E04FC19858182504553A6D,10737418240] [/atlas/atlaslocalgroupdisk/SAM/10G] <Unknown>:<Unknown>@osm 10 0 
{10017:"diskCacheV111.services.space.NoFreeSpaceException: space with id=3 does not have enough space"}

So, far so good / expected behavior.

When files gets to the storage using HTTP-TPC pull the behavior is different and it is possible to write to full spacetoken

$ date; gfal-copy --copy-mode=pull https://eosatlas.cern.ch/eos/atlas/atlasscratchdisk/SAM/vokac.src/10G/0 https://se1.farm.particle.cz/atlas/atlaslocalgroupdisk/fulldisk; date
Fri Aug 21 04:20:37 AM CEST 2026
Copying https://eosatlas.cern.ch/eos/atlas/atlasscratchdisk/SAM/vokac.src/10G/0   [DONE]  after 57s
Fri Aug 21 04:21:35 AM CEST 2026

because HTTP-TPC automatically resize spacetoken

[root@se1.farm.particle.cz ~]# date; ssh -p 22224 -l admin localhost '\c SrmSpaceManager; ls spaces -e' | grep ATLASLOCALGROUPDISK
Fri Aug 21 04:20:21 AM CEST 2026
 3    spacemanager_linkGroup_heppool1   REPLICA   ONLINE         60 +  571881755980975 +               0 =  571881755981035                     ATLASLOCALGROUPDISK
[root@se1.farm.particle.cz ~]# date; ssh -p 22224 -l admin localhost '\c SrmSpaceManager; ls spaces -e' | grep ATLASLOCALGROUPDISK
Fri Aug 21 04:21:46 AM CEST 2026
 3    spacemanager_linkGroup_heppool1   REPLICA   ONLINE          60 +  571892493399215 +               0 =  571892493399275                     ATLASLOCALGROUPDISK

This is really unexpected behavior of our dCache 11.2.6 (headnode) and 11.2.4 (disknodes).

(our storage pools are not completely allocated by existing spacetoken size for operational reasons)