Not only are we required to store trash for 7 days for free, because “what if the satellite was wrong, what’s worth it …”, so the data is stored longer!
1 Like
I don’t think trash is deleted exactly 168 hours from when it was created. There’s almost certainly a job that runs periodically looking for old trash to delete. It probably hasn’t run yet.
If those files are still there in a few days then there may be a bug.
2 Likes
As I think It must be 7 days and not an hour more. Why satellite(!!!) protect them self from errors for free?
1 Like
July 8th 00:00 - July 1st 00:00 = 168 hours
4 Likes
Trash is a bane to SNOs.
- CP + RM instead of just MV which causes disk thrashing.
- Trash is unpaid.
2 Likes
Oh! Shame on me. 
UPD: hmm, no. Jul 1 14:00 + 168h = Jul 7 14:00
3 Likes
I do that all the time… some programs start counting from zero… some from one…
The most fun is counting 11 fingers with my kids…
On this hand: 1,2,3,4,5 fingers.
On the other hand: 10,9,8,7,6 fingers.
5+6 = 11
See?! I have 11 fingers!
2 Likes
Is it?
Please tell me why I should be worried about this 0.07% of stored data?
And now we’re worrying about even a fraction of that that may be stored longer (and actually wasn’t yet).
The mv operation might not be optimal, but compared to the ingress you get in the same period of time you can hardly say that’s thrashing the HDD’s.
1 Like
What about this?
More than 8% is unpaid trash.
1 Like
This is from yesterday. Not getting anymore ingress due to trash. Another node at home has 1.2tb stored and 320gb trash, but can’t take screenshot right now since i’m not home.
1 Like
one of my nodes:
1 Like
I have to say mine is pretty bad as well and I’ve ran mine 24/7 no down time. Trash has filled up pretty fast this week alone. So no more ingress for me.
Second node with a pi4
1 Like
I have a feeling that people that has fast nodes are able to delete the pieces as the requests comes in. SNOs with slower nodes will get the garbage collection/trash and stays there for 7 days. This is why @BrightSilence is not seeing it on his since he is running the storagenode on high end hardware.
1 Like
It’s probably not the speed of the system more like the hard drive because it’s a SMR and it can’t keep up with it. Really disappointing I wish there was a more efficient way to delete or move files espically for SMR drives…
1 Like
So everyone with big trash post your specs and uptime in the last 30 days
2 Likes
It’s not that high end, it’s running on a NAS (DS3617xs) which is running 3 nodes total. And this was actually a node on an external USB drive that’s not that fast. Other 2 nodes look similar at around 0.1% trash one of them is connected with USB2. 9 minutes down time over the past week.
1 Like
Sorry still at work, essential worker so I’m replying in between breaks.
The screenshot I provided above is running on a DS418Play, 4 disk raid 5 but one of the disks are SMR. Has always been up, only down when it upgraded to new version.
Node at home is a Microserver N40L with 4 disks but no SMR drives. All CMR. 1.2tb used with around 300gb trash. Has always been up besides upgrading to new version.
1 Like
Maybe there is an IO factor to trash… i remember my node working a lot on doing big deletions, but then the storagenode software changed, the people left with massive amounts of trash… could be affected by new code which attempt on keeping IO reasonable…
now that trash is displayed on the dashboard one should think it’s partly because they are about ready to look into that problem, or interested in getting an idea of how bad the issue really is…
my node is on a zfs pool 3 x raidz1 using hdd’s with ssd cache’s
can’t say what my trash size has been, because i never bothered checking… but since the last updated it’s been pretty consistent at around 5gb.
and have had brief periods of downtime and server crashes over the last week, most about 15-20min and one time at a total of 100min… (if thats useful information to anyone)
1 Like
Going by your trash size of 84GB and assuming this data sticks around on average for half a day. (I think trash is cleared once a day)
So, 84/8 = 10.5GB = 0.0105TB. Let’s divide that by 2 to compensate that there is only too much trash for half of the day on average and then multiple by 1.5 for payout.
Where would you like to receive your 0.8 cents?
How about we say this is covered by the hundreds of dollars of surge payouts that you received for no reason at all. Or the one time bonus of 133.7 STORJ that just appeared out of nowhere for everyone?
Or we just change it to say trash stays around for at most 8 days. I’m fine with either. But lets not try to make it sound like 0.8 cents makes any difference whatsoever.
I am surprised about the difference in trash sizes on different nodes though. Has anyone with larger trash sizes seen delete failures in their logs? (If you use the successrate script, make sure you have the latest version. It had a bug that didn’t show delete failure correctly until recently.)
2 Likes