Bloom dont work or why my trash is empty?

Really? @littleskunk

A middle ground would be to put a limit to trash like a fixed X TB or a percent of total storage available. So in a short time, if there is to much data sent to trash, only X TB would be kept for 7 days and the oldest deleted even if it has less than 7 days.
In this way we can better plan our upgrades and etc, and would not have any more discussions about this topic.

1 Like

Yes that is correct. In times with almost no garbage collection changes the risk for bugs is low and a storage node could wipe the trash folder with no penalty. Don’t get me wrong. Even in these times there is a risk. For example a satellite could burn down and we are forced to restore the satellite from backup. Part of that procedure is also to restore all data from the trash folder on the storage node side. Nodes that don’t keep the files in the trash folder could get disqualified basically in any situation that requires us to restore the trash folder.

Now in addition to that risk we are currently also changing a lot around garbage collection. So that increases the risk of a bug and us having to call restore from trash. I have deleted the trash folder on my own storage nodes in the past but right now I don’t risk it. I don’t want to get disqualified for a simple bug. I don’t want to get disqualified for ignoring the fallback option that was implemented for this exact reason. At least not for the next few months. I might wipe my trash folder in a few month when all the garbage collection changes are stable enough to risk it again.

1 Like

But right now nodes suffering the most from the trash thing. When looking at my oldest node I see trash at 3.5 TB and still growing. All those fancy filewalkers working for a week or more and I don’t know when this comes to an end. Meanwhile almost all uploads failing because of race lost.

I will take the risk now for that node and see what happens… :sunglasses:

When trash was first proposed it was mentioned that it was supposed to be a temporary solution:

I wonder if it would better to invest developer hours in this potential other solution than to “cleanup” this trash situation.


It would be better to do so.
But why should they? Developer hours do cost money. Keeping the trash on our nodes does not cost them money.
It will only be of interest if no more storage space is available for the complete network.


TrueNAS stopped using them in their ZFS-based NAS, and Seagate explicitly stated this is a bad idea. They are probably amateurs who are also not using SMR drives the right way.

I have no intention of arguing with you. If one understands how SMR drives work and how they should be interacted with (what actions need to be taken on the host’s part), they can be successfully utilized. Honestly, I’m rather pleased that there’s a prevailing notion that SMR drives are unsuitable for any use, as it allows me to purchase these drives quite affordably. Just for your information: I have a ZFS setup consisting of 60 SMR drives of 5TB each, which has been running smoothly for 4 years now. Of course, some drives have failed during this time (I think I’ve replaced about 10 drives), but the resilver process has been trouble-free.

If your node is not full, what difference does it make to you if some free space is used for trash? None.

Well, I have 9 of them full… at least they were full until the changes in bloom filter took 2 TB down from each.