This is a side effect, not the goal. Technically you can remove it, but if there would be need to restore it - your node will be disqualified.
What’s the difference if the piece remains in place or is moved to trash? It is still there and can be used. If the sat needs it, the node will find it, remove the expiration time and the piece remains.
For the payment part… the node would know to make the difference; it will count the good pieces in “storage used” and marked pieces in “trash”. So it will show you on the dashboard both, like now. The satellites know what to pay for, like now. You won’t see them in different folders like now, but who realy stais and counts files in Trash anyways? And even now we have a big difference between sats and nodes, and we are not payed for the difference?
So what will change in the payment scheme? Nothing!
1 Like
You need to store the expiration date somewhere. The moving to the trash is an easy one - you may just check the last modification date and compare with the current date, fast and simple.
Of course, you may also use a header of each piece, but this is mean, that each piece must be modified, but since it has a signature - this invalidate it. The other way is to store in the database… Ok, and if the database is corrupted, these pieces will be never removed.
So, the chore for the Trash is another trade off between the durability and speed.
2 Likes
In memory. When a node receives a bloom filter, the node is supposed to deal with it with no delay. And as soon as pieces were scanned and moved to trash, the bloom filter is no longer useful. The issue is that this design did not take into account slow storage, and hence the ticket quoted by @jammerdan.
Moving to trash is exactly a way of marking “for deletion”. It has the nice features of (1) being simple, (2) being guaranteed to work atomically, (3) disabling access to the file, (4) with no performance impact on download requests, (5) being guaranted to work on all file systems. It is indeed kinda slow though.
You cannot assume inodes have a way to store additional information (usually called extended attributes), because not all file systems support them. And of those file systems that do, sometimes they come with performance overhead on each file access, not just trash handling.
But there are some other possibilities which could be explored by courageous storage node operators with coding skills.
2 Likes