Updates on Test Data

[nerdatwork]

@MarviBiene

but it’s not updated to the node itself?

In my observation, even operating system ( Windows ) won’t show any new free space after TTL data is being deleted. This makes me wonder if TTL data is really being deleted or not as we only see “count” line in the log not the original deleted expired piece.

[Vadim]

it not deleting all at once, step by step as was uploaded.

[nerdatwork]

I saw multiple lines of count: 600k which should update at least 10s of gbs. I had no ingress so the number didnt update at all. I need to further investigate.

2024-06-29T17:04:56Z    INFO    collector       collect {"Process": "storagenode", "count": 664118}
2024-06-29T22:52:07Z    INFO    collector       collect {"Process": "storagenode", "count": 666053}
2024-06-30T05:29:22Z    INFO    collector       collect {"Process": "storagenode", "count": 667016}
2024-06-30T09:20:18Z    INFO    collector       collect {"Process": "storagenode", "count": 667057}
2024-06-30T11:11:36Z    INFO    collector       collect {"Process": "storagenode", "count": 638589}

[Alexey]

Accordingly this issue:

Updates on Test Data

Not on the nodes… It seems deleting expired TTL pieces does not update the used space stats.

I think it’s not updating databases with a new free space.
So the workaround would be the same - restart the node with a used-space-filewalker enabled, until the new version would be rolled out.

[Alexey]

It’s interesting. It should be deleted. Just like @Vadim said - with the same time intervals (if the TTL was the same though).

[snorkel]

What’s the point? The TTL data is removed daily. The startup piecescan is run only at restart and it takes days. Should we keep restarting the nodes when the FW finished? It’s pointless. Just fix the bug and release those updates quicker. THIS SHOULD BE THE PRIORITY NUMBER ONE!

[JoshieGarza]

this could explain why 12 days after reducing the allocated space (from several TBs to 1TB because i want to migrate the SN to another disk faster), the used space is still the same.

[Alexey]

I do not think that you need to restart it daily. However, If your node is rendered as full, but you have a free space, you may restart it to make updates.

And I do not suggest it as a fix, it’s a workaround until the fix would be rolled out.

[flwstern]

I think you have to do some redesigns alexey. To much issues for everyone.

[Alexey]

I know, and there is a work in the team, but lightly exposed right now
like

Disk usage discrepancy?

Ah, if we’re talking about the manipulation of the files, then yes, as you rightly point out, we have lots of room for improvement. I was only talking above about the directory traversal piece by itself. Your suggestions are good ones and some we’ve talked about doing before. Some are harder than others. For example, giving up on the temp dir would mean we need some other way to differentiate partial uploads from full, intact blobs. We could try to use a database to keep track of what files a…

Has it ever been considered to use in-memory databases?

It would require a separate chore to move data from the operational database to the historical database, it also will require to redo how this information is handled in the storagenode API (it must combine data from two sources (three if we account both operational databases - in-memory and on the disk, also historic DB) for each metric). it’s as complicated as it sounds. As result - it likely slow down the node and anything what would request these metrics. I do have more hope into this resea…

Design draft: a low I/O piece storage

Thanks for this design doc @Toyoo, It’s a well written design, I like it. And finally I had some time to collect my thoughts. TLDR; I like the approach, but I am not sure about the implementation. So far I have heard about multiple attempt to improve the piece store. They are usually save the metadata of pieces in a database like system and save the raw data in custom files. (technically it would be possible to store both metadata and data in database, but it’s quite slow. I tried it, and mea…

[Roxor]

Storj itself is relatively lightweight: even with current ingress. But seemingly running used-space-filewalker 24x7… 100% iops all-the-time… does get tiring. Good thing I’m a patient man

[Andrew]

Devs, do you recommend to update to 1.107.3? Or should we wait something?

[snorkel]

Wait! Because if you recreate the container, it could go down a version and the databases are incompatible. You will end up updating it again or deleting the databases.

[pangolin]

@snorkel

it could go down a version

The version server url is not hard coded. This can be used to avoid such downgrades or to let it install any version you want.

[littleskunk]

@Andrew

Devs, do you recommend to update to 1.107.3? Or should we wait something?

We have started the normal rollout procedure. Please be patient and follow the rollout process. If we would all upgrade our nodes by hand we are risking to lose customer data. The rollout procedure is designed to mitigate that risk. If you feel the rush to install it faster please don’t do it on all of your nodes all at once. Better pick a single node first, let it run for a few hours - a day, upgrade like 50% of your nodes , wait again and last but not least the remaining nodes.

[PePeR]

Are you running some crazy benchmarks right now? Last 2 days all my nodes restart every few hours

[arrogantrabbit]

Find out why do they restart and fix it. It’s in no way normal.

[PePeR]

I think having 300gb egress of daily repair isn’t normal…

[littleskunk]

@PePeR

Are you running some crazy benchmarks right now?

I would say not more crazy than on other days. It should still be the same load.

What has changed is the TTL cleanup that now comes on top. Maybe that is too much for your storage node?

[PePeR]

probably… I will monitor it for few days and if its gonna keep going Im gonna just change config to full drives to not get more ingress. This should fix it temporarly