That is ok - It’s just test data, so everything can safely be removed 
Uploads now seems to go to my nodes :
Th3Van.dk
Do the Spiridon satellite use bloom filters, or other ways to delete removed bucket data from nodes?
Th3Van.dk
TLDR; it was not fully enabled, but should be working now.
I had to disable server side copy (it requires database which supports as of system time).
Looks to be working now. I am also testing repair / audit.
Now let’s see how many AUDIT’s i’m getting
Test - 10 million remote segments uploaded to Spiridon satellite.
I completed a test upload of 10,000,000 remote segments to the Spiridon community satellite.
Summary
Dataset layout
The upload consisted of:
- 10 Storj objects
- 1,000,000 remote segments per object
- 4,097 plaintext bytes per segment
- 4,097,000,000 bytes per object
- 40,970,000,000 logical source bytes in total
Each object used:
- 125 multipart parts
- 8,000 remote segments per part
- 32,776,000 bytes per multipart part
All ten objects committed successfully and were listed by the satellite at exactly 4,097,000,000 bytes each.
Redundancy and piece count
Spiridon returned the following redundancy scheme:
Required shares: 10
Repair shares: 12
Optimal shares: 14
Total shares: 16
Share size: 256
For these 4,097-byte remote segments, the satellite issued signed piece limits of 768 bytes per piece.
Therefore, across 10 million segments:
Authorized piece positions:
10,000,000 × 16 = 160,000,000
Minimum threshold successes:
10,000,000 × 14 = 140,000,000
Uplink initially activates all 16 candidates. Once 14 valid signed PieceHash results have been received, the remaining work is cancelled, although some uploads may win the race and complete before cancellation takes effect.
An earlier fully instrumented test of 128,000 identical segments measured:
Successful pieces: 1,910,151
Cancelled attempts: 137,847
Average successes: 14.923 per segment
If that measured ratio remained representative during the 10-million-segment run, the estimated physical result would be approximately:
Successful physical pieces: ~149.23 million
Cancelled piece attempts: ~10.77 million
This is an estimate, not an exact count for the 10-million-segment run. Full per-piece instrumentation was deliberately disabled because it would have produced approximately 34 GiB of JSONL logs and would have affected benchmark performance.
The exact bounds are therefore:
Authorized piece attempts: 160,000,000
Successful pieces: at least 140,000,000
Likely successful pieces: approximately 149,000,000
Piece payload
At 768 bytes per complete piece:
Minimum successful piece payload:
140,000,000 × 768
= 107,520,000,000 bytes
Estimated successful piece payload:
149.23 million × 768
≈ 114.61 GB
Maximum authorized piece payload:
160,000,000 × 768
= 122,880,000,000 bytes
These values are application-level piece payload, not actual network traffic.
Uplink configuration
The benchmark used a modified test-only Uplink build with:
Remote segment size: 4,097 bytes
Multipart parallelism: dynamic d75
Dynamic hard maximum: 128
Peak active parts: 125
Source IP count: 8
Source-IP strategy: node-hash
Piece scheduling: normal/default
Object transfers: 1
All eight source IPs were used. No satellite, storage-node, signature or redundancy changes were made.
Performance
Results across all ten objects:
Total upload time: 13,930.81 seconds
3:52:10.81
Mean time per object: 1,393.08 seconds
23:13.08
Fastest object: 23:03.68
Slowest object: 23:23.95
Aggregate segment rate: 717.83 segments/second
Mean Uplink CPU: 440.4%
approximately 4.4 CPU cores
Maximum peak RSS: 33,687,280 KiB
approximately 32.13 GiB
The unusually high memory consumption came from keeping up to 125 multipart parts active, each independently processing thousands of very small remote segments.
Network traffic
Measured across the eight source interfaces:
Logical source bytes: 40,970,000,000
Measured NIC TX: 361,649,647,638 bytes
NIC TX/source: 8.8272x
Measured NIC RX: 272,370,079,306 bytes
The high network amplification is expected for extremely small segments. Each 4,097-byte source segment creates up to 16 separate piece-upload operations, with order setup, TLS/DRPC, piece hashes, signatures, acknowledgements and cancellation traffic dominating the actual payload.
Test date and duration
The test was performed on October 4, 2026.
Start: 2026-10-04 15:05:33 UTC
Completion: 2026-10-04 18:57:46 UTC
Conclusion
Objects committed: 10/10
Remote segments: 10,000,000
Multipart parts completed: 1,250/1,250
Upload failures: 0
Incorrect remote sizes: 0
Total committed bytes: 40,970,000,000
Total elapsed: 3 hours, 52 minutes, 13 seconds
The ten objects remain stored on the Spiridon test satellite for further inspection.
Th3Van.dk
Any change that the Spiridon satellite would support IPv6 in a not so distant future? 
All my nodes and the uplink sandbox are currently using dual-stacked IPv4 and IPv6
Summary
{
"blake3": "657274e1fb7f9da998d5f2ec8828226f5b7ae62f23b82e39dfb54a85df47052b",
"blake3_threads": 16,
"decision": 104,
"elapsed_seconds": 20.2155282497406,
"ended_epoch": 1791516610.8330765,
"event": "download_complete",
"exit_code": 0,
"ip_family_mismatches": 0,
"ipv4_bytes_received": 1871435840,
"ipv4_bytes_sent": 526643,
"ipv4_connections": 63,
"ipv4_source_ips": [
"37.35.96.150",
"37.35.96.151",
"37.35.96.152",
"37.35.96.153",
"37.35.96.154",
"37.35.96.155",
"37.35.96.156",
"37.35.96.157"
],
"ipv6_bytes_received": 0,
"ipv6_bytes_sent": 0,
"ipv6_connections": 0,
"ipv6_source_ips": [],
"key": "mixed-daily-pool/files/20261009-020-022864467965B-657274e1fb7f9da998d5f2ec8828226f5b7ae62f23b82e39dfb54a85df47052b.bin",
"satellite_connections_observed": 8,
"satellite_ip_family": "ipv4",
"satellite_remote_addresses": [
"88.99.99.247:7777"
],
"satellite_source_ips": [
"37.35.96.150"
],
"size_bytes": 22864467965,
"started_epoch": 1791516590.6175482,
"storage_node_ip_family": "ipv4",
"timestamp": "2026-10-09T03:30:14.320941Z",
"validation": "PASS"
}
Th3Van.dk