Metadata storage creates file revision for every upload

[rhafer]

Describe the bug

As part of addressing #8938 I experimented a bit with the the sharecache implementation in reva pkg/share/manager/jsoncs3/sharecache/sharecache.go while doing that I noticed that with every update (i.e. upload) of the cache file a file revision is created in the storage.

For my experiments with a cache for roleassignments keyed by roleid that means I end up with 1000 file revisions of the cache files after creating 1000 users. This accumulates quite some wasted space (and probably quite some additional I/O).

We should think about allowing to disable versioning on the metadata storage.

[kobergj]

We should think about allowing to disable versioning on the metadata storage.

Just to be clear since it is a P2:

Scope of this ticket is to deactivate versioning for the storage-system service?

@rhafer @micbar

[micbar]

Scope of this ticket is to deactivate versioning for the storage-system service?

Correct.

[micbar]

Good addition: We also need a CLI command to purge old versions.
Decision to do the CLI command as a follow up. @tbsbdr

[micbar]

Needs backport to stable-5.0

[kobergj]

backport overview:

• reva pr: Backport Disable versioning cs3org/reva#4743
• [ ]~ ocis pr:~
• backport finished

UPDATE: Backport not possible. It depends on cs3org/reva#4562 which has not been backported.

We can backport the cli, then this can be scheduled in a cronjob until next version.

[micbar]

We need to talk about backporting please with @d7oc

[d7oc]

Also adding @wkloucek here as I will not be available next week.

[kobergj]

It depends on the posix PR which also contains a huge refactor of the decomposedfs. I would not recommend backporting this. But if you insist we can backport both PRs.

I still think backporting the cli would be the more feasible (and safe) solution

[micbar]

Done in sprint 27.

Backporting of the CLI needs extra ticket.