Trash does not go away in 7 days

[jammerdan]

@thepaul

I wasn’t aware of those.

Then you are probably also not aware of my other trash issue here:

Another issue with trash

Now what is going on here? Node version: 1.102.3 /storage/trash/.trash-uses-day-dirs-indicator is present But no date directory: /storage/trash/ukfu6bhbboxilvt7jrwlqk7y2tapb5d2r2tsmj2sjxvw5qaaaaaa/2a at least on that satellite. Same node other satellite: /storage/trash/v4weeab67sbgvnbwd5z7tweqsqqun7qox2agpbxy44mqqaaaaaaa/2024-04-23/2a

@thepaul

That would definitely break trash collection.

Great.

@thepaul

That means the per-day dir transition ran more than once, but it’s not clear how that could happen.

I have it on more than one node and others have it as well.

@thepaul

(preferably with stat(1) or something like it to show subsecond precision)?

If the higher layers and the indicator file all have birth times

Unfortunately birth time does not get recorded. It has only access, modify and change time.

/trash/.trash-uses-day-dirs-indicator
Access: 2024-04-13 06:23:09.153704449 +0300
Modify: 2024-04-13 06:23:09.153704449 +0300
Change: 2024-04-13 06:23:09.153704449 +0300

/trash/ukfu6bhbboxilvt7jrwlqk7y2tapb5d2r2tsmj2sjxvw5qaaaaaa/2024-04-13
Access: 2024-04-13 05:12:47.112192010 +0300
Modify: 2024-04-13 05:20:39.930751195 +0300
Change: 2024-04-13 06:23:05.453527813 +0300

trash/ukfu6bhbboxilvt7jrwlqk7y2tapb5d2r2tsmj2sjxvw5qaaaaaa/2024-04-13/2024-04-13/
Access: 2024-04-13 03:18:03.539695399 +0300
Modify: 2024-04-13 03:18:03.539695399 +0300
Change: 2024-04-13 05:20:39.930751195 +0300

/trash/ukfu6bhbboxilvt7jrwlqk7y2tapb5d2r2tsmj2sjxvw5qaaaaaa/2024-04-13/2024-04-13/2024-04-13/
Access: 2022-11-18 16:12:12.827925254 +0200
Modify: 2022-07-17 12:28:09.453219325 +0300
Change: 2024-04-13 03:18:03.539695399 +0300

I don’t know if it is helpful without birth date.

@thepaul

For the part of the storagenode software, it has to avoid deleting things that aren’t expected, in case of configuration mistakes or a bug causing confusion about where important files are.

Fine then. But I don’t understand why you would expect empty trash date folders. According to @elek the idea is to simply delete the folders that are old enough:

@elek

Nested date folders in trash makes it very easy to purge old trash data. You don’t need to check each trash files on by one for the deletion time (which is the creation date of the trashed file). You can just delete folders which are old enough…

And was there a bug that did not even delete empty date folders:

@Alexey

Yes, but I suspect that we do not remove folders actually even if they are empty. Perhaps it’s a bug.

But well, then you need to find a way to tell the node software that it is fine to delete these nested folders and make the trash collection work again on the affected nodes. As I have these on more than on one node and I checked only a few when that update that performed the migration had been applied, I cannot check every node and perform manual cleanup of the erroneous folder structures.