Hi @elek !
NodeID: 12epLYjk2PGLQzTdeaNqnrNF4qGSfZouB2rSKWQmXLCx5oR1Eqq
Here is an archive with a list of pieces in the catalog of the satellite US1 : Files-US1.zip | Storj
PS:
I uploaded via the web interface - the speed is very low - 2444 MB took more than 40 minutes to upload.
Hi @Th3Van !
Total current watt consumption for SM01 : 1949
So it’s not easy to do this kind of work - lists of pieces - consumption has skyrocketed 
What is the final cost of electricity for you as a consumer? You gave a link to the Nordpool exchange, but these are wholesale prices and they are far from what the end consumer pays in the end.
If it’s not a secret, what are the average payments per month, for example for December.
With the current profitability that you see - 1.24USD per TB, the cost of electricity is important… As I understand, your IP addresses are free.
Of course, I use rclone and the native client for backups, but in this case it was more convenient for me to do it in the browser. And yes, and one stream of my speed test gives at least 700 Mbit to servers in Germany, so it seems to me that there may be a problem with the performance of the storj browser gateway.
no, it’s just not designed for fast uploads. It’s only a quick start tool to upload small files and check how it works.
For the real usage you need to use tools, not a browser.
Any problems with some HDD models so far? Any favorites? Any not-favorites regarding performance and reliability?
Th3Van.dk
We are primary using Seagate Enterprise SAS HDD’s and are pretty happy with that.
There has been a few HDD fails, but if you are planning ahead and use RAID with hotspares, things usually turn out to be working fine, with very little (if any) downtime for our customers.
For the 105 HDD storj.dk server/jbod, there has been just one HDD fail in the last 4 years, though i was able to copy all the data to a new HDD, so the failed hdd wasnt totally dead.
Th3Van.dk
False hope bro…
Check it tomorrow. It will climb back to the avg rate.
I’ve discovered this issue since around october. I thought I made some mistake with my old nodes, so I’ve made a brand new 500GB node which filled up quickly. I had a constant 20% difference. Was not able to solve it.
The AVG disk space used this month climbed up sometimes just like yours in the picture… (even way to high just like here), but in the next day the 20% diff came back.
It’s just for fun. 
I restarted the node to modify some settings and the bonus was gone. I know that the present day has fluctuations on graph. I don’t pay attention to it.
The Select/Commercial program removes the /24 restrictions for you, right? Like you could start 60 nodes across those disks… park them across 60 sequential forwarded ports… and it wouldn’t matter that they’re all behind a single IP? Nice! 
I wonder if that could help accelerate filling your non-Select nodes as well? Like if Storj isn’t flagging your node identities as “select”… and instead they’re just whitelisting some of your IPs… then if your regular nodes are behind those same IPs they may opt-out of the /24 restriction too?
Yes, that is how i understands it.
Exactly.
My guess is that there will be a dedicated satellite for nodes joining the select/commercial program, or nodeIDs are added to a special select/commercial program node list, that has other set of “rules” than public nodes.
But again that is all guessing. I will know more when both the SM 64 core server and JBOD chassy has arrived.
Th3Van.dk
Thank you all the shared data @Th3Van @AiS1972 @mgonzalezm @snorkel @daki82
I downloaded all data, and now we have enough samples to compare it with the database…
I will compare them with the satellite database (however it’s a slow process, it requires operation on a very huge shadow database. But I am on it)
OFFTOPIC:
It’s kind of orthogonal for the discussion of the TOPIC, but Storj Select uses the us1 satellite, but different placements. Placements are like regions, but defines how to store data, including the placement rules (like use or not /24 rules). It’s kind of an extension to geofencing…
I restarted 2 nodes in 2 machines (Synology DS220+, 18GB, Exos drives), same capacity, same space occupied, same setups; both machines are running 2 nodes, but only the test ones are restarted:
In Lazy mode, the FW run takes more time, but the system is more responsive and you don’t loose audit online score.
In non-Lazy mode, the FW runs quicker, but the system is less responsive and I lost ~3% of online audit score, from 99.8 to 97.2.
Unfortunetly, bot have ~1TB occupied space discrepancy from satellites report (Average … current day).
wich FS and config is used?
Ext4, noatime, log level fatal, no ssd.
https://github.com/storj/storj/commit/12dd732
We’re getting close to solve this… 
Not sure if related to something or I was just lucky, but had one node I was migrating to ext4 the other day. This took a few days with storagenode process being shutdown.
Once done, I rebooted the VM to remove the old LV, updated the amd64 binary to 1.95.1, started it and shortly after it apparently received a bloom filter.
It was running okay moving significant amounts of data to trash, but then the lazy storagenode process was killed because of OOM at roughly 0.73TB of trash.
The other storagenode process handling uploads and downloads is running fine still with different PID and with uptime now of over 23 hours.
This node is configured with 4GB of RAM, so just checking if maybe someone can take a look at the recent changes to see if there maybe is some memory leak somewhere or it was just coincidence.
Thank you.
Edit: It even looks like it completed the GC and then it was killed.
2024-01-18T02:52:28Z INFO lazyfilewalker.gc-filewalker starting subprocess {"process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S"}
2024-01-18T02:52:28Z INFO lazyfilewalker.gc-filewalker subprocess started {"process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S"}
2024-01-18T02:52:28Z INFO lazyfilewalker.gc-filewalker.subprocess Database started {"process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "process": "storagenode"}
2024-01-18T02:52:28Z INFO lazyfilewalker.gc-filewalker.subprocess gc-filewalker started {"process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "createdBefore": "2024-01-10T17:59:59Z", "bloomFilterSize": 2097155, "process": "storagenode"}
2024-01-18T07:16:09Z INFO lazyfilewalker.gc-filewalker.subprocess gc-filewalker completed {"process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "process": "storagenode", "piecesCount": 30105220, "piecesSkippedCount": 0}
2024-01-18T07:16:23Z INFO lazyfilewalker.gc-filewalker subprocess exited with status {"process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "status": -1, "error": "signal: killed"}
2024-01-18T07:16:23Z ERROR pieces lazyfilewalker failed {"process": "storagenode", "error": "lazyfilewalker: signal: killed", "errorVerbose": "lazyfilewalker: signal: killed\n\tstorj.io/storj/storagenode/pieces/lazyfilewalker.(*process).run:83\n\tstorj.io/storj/storagenode/pieces/lazyfilewalker.(*Supervisor).WalkSatellitePiecesToTrash:130\n\tstorj.io/storj/storagenode/pieces.(*Store).SatellitePiecesToTrash:555\n\tstorj.io/storj/storagenode/retain.(*Service).retainPieces:325\n\tstorj.io/storj/storagenode/retain.(*Service).Run.func2:221\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}
[Thu Jan 18 07:16:22 2024] Tasks state (memory values in pages):
[Thu Jan 18 07:16:22 2024] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[Thu Jan 18 07:16:22 2024] [ 1013] 0 1013 4551 646 49152 0 0 systemd-udevd
[Thu Jan 18 07:16:22 2024] [ 1372] 0 1372 617 25 40960 0 0 acpid
[Thu Jan 18 07:16:22 2024] [ 1977] 0 1977 721 483 49152 0 0 dhcpcd
[Thu Jan 18 07:16:22 2024] [ 2079] 104 2079 458610 2399 212992 0 0 grok_exporter
[Thu Jan 18 07:16:22 2024] [ 2115] 315 2115 837 483 45056 0 0 lldpd
[Thu Jan 18 07:16:22 2024] [ 2117] 315 2117 811 363 45056 0 0 lldpd
[Thu Jan 18 07:16:22 2024] [ 2151] 0 2151 2560 129 57344 0 0 syslog-ng
[Thu Jan 18 07:16:22 2024] [ 2152] 0 2152 76675 762 94208 0 0 syslog-ng
[Thu Jan 18 07:16:22 2024] [ 2217] 0 2217 1876 1844 53248 0 0 ntpd
[Thu Jan 18 07:16:22 2024] [ 2247] 0 2247 3514 1146 61440 0 0 snmpd
[Thu Jan 18 07:16:22 2024] [ 2279] 0 2279 1733 560 53248 0 -1000 sshd
[Thu Jan 18 07:16:22 2024] [ 2307] 1001 2307 44058 4770 110592 0 0 python3
[Thu Jan 18 07:16:22 2024] [ 2343] 0 2343 733 151 45056 0 0 agetty
[Thu Jan 18 07:16:22 2024] [ 2344] 0 2344 733 152 49152 0 0 agetty
[Thu Jan 18 07:16:22 2024] [ 2345] 0 2345 733 141 49152 0 0 agetty
[Thu Jan 18 07:16:22 2024] [ 2346] 0 2346 733 151 40960 0 0 agetty
[Thu Jan 18 07:16:22 2024] [ 2347] 0 2347 733 139 45056 0 0 agetty
[Thu Jan 18 07:16:22 2024] [ 2348] 0 2348 733 152 49152 0 0 agetty
[Thu Jan 18 07:16:22 2024] [ 2412] 1001 2412 434705 78558 950272 0 0 storagenode
[Thu Jan 18 07:16:22 2024] [ 2455] 0 2455 973 470 45056 0 0 crond
[Thu Jan 18 07:16:22 2024] [ 14394] 1001 14394 1137798 823288 6754304 0 0 storagenode
[Thu Jan 18 07:16:22 2024] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=storagenode,pid=14394,uid=1001
[Thu Jan 18 07:16:22 2024] Out of memory: Killed process 14394 (storagenode) total-vm:4551192kB, anon-rss:3293152kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:6596kB oom_score_adj:0
That would still not be the solution i think,
what i saw today, a filewalker again wasn’t able to finish a walk,
because some shooting down (restart).
Whether it was some software error, hardware error or another forced auto-update
(lately i see version after version being pushed to my nodes in last 30 days)
those events interfere with filewalker,
Would like to see a filewalker to be able to determinate which sattelite it need to walk FIRST.
Would like to see a filewalker to be able to somehow remember where he was interupted, and resume more of less from that point after node restart or unexpected restart, and not a whole walking process from the beginning… (i mean the “.used-space-filewalker”) my HDDs are constanly filewalking for weeks now, no sight of end to that. And average acces times are awsome 4-6ms or 12ms, not a slow HDDs problem, or crappy controller i got a professional one now…)
