Look like setting pieces.delete-to-trash not working anymore

[d4rk4]

root@50:~# grep trash /opt/storj/data/config.yaml 
# move pieces to trash upon deletion. Warning: if set to false, you risk disqualification for failed audits if a satellite database is restored from backup.
pieces.delete-to-trash: false
root@50:~# ls -lsah /opt/storj/data/storage/trash/qstuylguhrn2ozjv4h2c6xpxykd622gtgurhql2k7k75wqaaaaaa/
total 56K
5.0K drwx------    4 storj-storagenode storj-storagenode    4 May 23 00:32 .
 25K drwx------    7 storj-storagenode storj-storagenode    8 Mar 27 22:08 ..
 13K drwx------ 1026 storj-storagenode storj-storagenode 1.1K May 22 20:03 2024-05-22
 13K drwx------ 1026 storj-storagenode storj-storagenode 1.1K May 23 00:34 2024-05-23
root@50:~# ps aux | grep storage | grep -v grep
storj-s+  148901  8.3  3.9 2498260 334440 ?      Ssl  May18 517:08 /opt/storj/bin/storagenode run --config-dir /opt/storj/data
storj-s+  149444  0.0  0.4 1243992 36276 ?       Ssl  May19   0:51 /opt/storj/bin/storagenode-updater run --config-dir /opt/storj/data --binary-location /opt/storj/bin/storagenode

@elek

[Alexey]

Deleted pieces will be sent to trash by default

Hi SNOs, The next software upgrade includes a change that will by default send piece deletions to the trash rather than immediately removing them from disk. This is a temporary precaution to avoid failing audits for pieces that were deleted between satellite database backups if we have to restore from a previous backup. Each node still has the option to turn this configuration off, but we highly recommend you keep it on. It is very unlikely that we will have to restore from a satellite database…

[d4rk4]

Please review my message first

pieces.delete-to-trash: false

Node restarted at 18 of may, new folders in trash still generated 22.05 & 23.05

[d4rk4]

@Deleted pieces will be sent to trash by default

Each node still has the option to turn this configuration off,

This is broken for now =)

[Alexey]

I believe that feature flag has been removed that time, but I sent your report to the team.

[d4rk4]

I forgot version in my report - v1.104.5

[xsys]

Please what is the status of this?
Is pieces.delete-to-trash: false supposed to be working? (not working for me, v1.105.4)

[Alexey]

It should be. Do you see that it’s not?

[xsys]

I have this line in my config.yaml

since beginning of this node, and I’m getting

and

[Alexey]

Please measure the size of these folders. The high level - the trash folder as a whole.
Then check, that you do not have any non-empty subfolders with date later than your change.

P.S. also, I guess that this change would stop processing the trash. So, likely you would need to remove subfolders after 7 days manually…

[xsys]

@Alexey

date later than your change

I did not change it, i have pieces.delete-to-trash: false set up since the node’s beginning, never changed it.
The trash folder is 3.7 GB

the content goes like this:

[Ambifacient]

There is an open issue for this: Config option pieces.delete-to-trash: false looks to be ignored · Issue #7012 · storj/storj · GitHub

[xsys]

according to the link above, if I set pieces.enable-lazy-filewalker: false will it stop moving to trash folder?

[Alexey]

You may try it. It should work, but also I thought that this option should work too even for lazy, so we need a confirmation.

[xsys]

@Alexey

we need a confirmation

you mean from me/users or from developers?
I can see pieces going to trash, although as I said I have it turned off for months:

[xsys]

I set pieces.enable-lazy-filewalker: false yesterday (+ restart), and today new trash was created again:

[nerdatwork]

@xsys

I set

Did you make sure there are no leading or trailing spaces in that config line ?

[xsys]

yes, this is how it looks:

all characters visible:

[Alexey]

@xsys

you mean from me/users

From the fellow Storage Node Operators, yes. Only the SNO can truly confirm is it working or not. The developers may check that only if there would be a bug report on GitHub. Right now it’s not confirmed fully, so your help is appreciated.

@xsys

I set pieces.enable-lazy-filewalker: false yesterday (+ restart), and today new trash was created again:

Thank you for the confirmation!
I added your feedback to the issue.

[nerdatwork]

Release preparation v1.108

Yea kind of. It is deprecated for other reasons. Full story is here: Design draft: fixing deletes and server side copy Lets say this flag only works if the satellite sends you delete messages. On the satellite side that is just a feature flag and can be turned on and off. We would have to disable / enable server side copy accordingly. They don’t work in combination with delete messages. Which basically means on the current satellites there is no way to go back in time. But can still be useful f…

A good read.