I get this in my logs. I’m guessing it’ll come at some point? How long should it take?
2026-04-26T01:10:32Z INFO Current binary version {"process": "storagenode-updater", "service": "storagenode-updater", "version": "v1.148.3"}
2026-04-26T01:10:32Z INFO New version is being rolled out but hasn't made it to this node yet {"process": "storagenode-updater", "service": "storagenode-updater"}
The rollout process is designed to update nodes gradually, increasing coverage. At the moment it’s
If everything is good, the node should be updated within a week.
Do you have any problem with the current version?
Ok, sounds good. No issues with this old version. I’ll patiently wait. Thanks for the amazing support. First time I’ve ever needed it.
This is one of the distinguishing features of this project/team/company. My very first interaction with storj was – and still is – the best experience I ever had with how any company large or small handles reported issues.
That thread:
is still exemplary. I don’t think many here stop to think how unusually refreshing this is. This kind of attention to quality pretty much the sole reason I’m still hanging out around here.
upgraded one of nodes today to v1.153.2 (windoze) , and my allocated space went from 9tb to 6,08tb , issue is still ongoing with latest version
Hello @Morisey,
Welcome back!
How much space is used on disk and how much is used on the pie chart?
Please note - Windows lie about measure units, it uses binary accounting, but shows SI units, so you need to take a bytes amount for comparison and divide them on 1e12 to get SI TB instead of TiB.
P.S. if you were affected by this bug, your showed free space was 0.
free space 0 prolly shows up in case your node had no free space margin , mine have , it just lost 2,92Tb somewhere even it have proper config and free space on disk itself
Just installed v1.153.2 to some windows nodes. It seems like it now automatically adjusts the allocated space number if there is overallocation in config. Showing the really available space is ok in my opinion.
i don’t see any overallocation , i have available 9Tb , node configured to use 9Tb , it shows on dashboard 6.08Tb , with 5.37Tb used and 0.71Tb available , then where did almost 3Tb disappeared that’s available physically , in configuration , just not appearing in dashboard as available (check the attached screens)
I just put 153.2 on my linux node and its doing the same thing as 152.5 did, zero free space to write even though my drive has many TBs available and my allocated is much higher then whats currently used. Seems like the same bug.
v1.155 should include fix for all known space issue problem. RC is out, if you adventurer, feel free to test.
(Rollout will happen later, first we will test it in select network as well. But part of the problems couldn’t be reproduced on select network, as we have hashstore only servers there.)
Is there any solution to broken logs that can’t be reclamed? I have alredy 26tb of reclamable space and it rising, because part of nodes have broken logs.
I wonder if that’s what the recent lost piece amnesty feature will be used for? It sounds ideal for repairing/replacing hashstore data logs that can’t be compacted due to corruption.
amnesty it litle bith other thing, problem that this pieces cant be deleted, and also all others cant be deleted, as compaction just crash on them.
How can I check my nodes? What error message should I search for?
If you have something like this,
2026-05-29T11:12:44+03:00 ERROR hashstore compaction failed {“satellite”: “12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S”, “error”: “hashstore: writing into compacted log (rec={key:7b59278f45885adfb3134665a3031e059f4eda6ad8df1eae85c73207b27a3027 offset:1072137152 log:20 length:2174976 created:20325 (2025-08-25) expires:0 (1970-01-01) trash:false}) (from=L:\hashstore\12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S\s0\14\log-0000000000000014-00000000) (size=1073761280): EOF”, “errorVerbose”: “hashstore: writing into compacted log (rec={key:7b59278f45885adfb3134665a3031e059f4eda6ad8df1eae85c73207b27a3027 offset:1072137152 log:20 length:2174976 created:20325 (2025-08-25) expires:0 (1970-01-01) trash:false}) (from=L:\hashstore\12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S\s0\14\log-0000000000000014-00000000) (size=1073761280): EOF\n\tstorj.io/storj/storagenode/hashstore.(*Store).rewriteRecord:1395\n\tstorj.io/storj/storagenode/hashstore.(*Store).compactOnce.func8:1142\n\tstorj.io/storj/storagenode/hashstore.(*Store).compactOnce:1152\n\tstorj.io/storj/storagenode/hashstore.(*Store).Compact:855\n\tstorj.io/storj/storagenode/hashstore.(*DB).performPassiveCompaction:568”}
I checked all nodes, no such error found. Overall reclaimable is 3.5 percent.