Allow appdata being stored in a separate object storage multibucket #26142
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Morris Jobke <[email protected]>
MorrisJobke
requested review from
rullzer,
icewind1991,
ChristophWurst and
juliushaertl
|
I would much prefer mounting a separate |
| @@ -591,6 +625,7 @@ private function copyFile(ICacheEntry $sourceEntry, string $to) { | |||
| $targetUrn = $this->getURN($targetEntry->getId()); | |||
|
|
|||
| try { | |||
| $this->verifyStorage($path); | |||
There was a problem hiding this comment.
Suggested change
| $this->verifyStorage($path); | |
| $this->verifyStorage($to); |
|
what's the state here? |
Most likely this needs to be solved in a different way:
Let's close this one then. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Disclaimer: This originated in a custom patchset and I just brought it into a bit better shape. It is still far from a proper solution, but I want to bring this up for discussions.
Why?
By default on a multibucket object storage setup the appdata files are all put into the bucket 0. This might cause some problems on various systems, where there is a lot of data (which are obviously the ones with an multibucket object store). The idea here is to allow to also put the appdata into a separate list of object store buckets to not have a lot of data (previews for example) in a single bucket.
What this does:
It basically replaces the object store instance on the fly (right before the write/read/unlink) operation with the one that fits the current path. It's definitely not a good way of handling this. Best would be to put this one layer above and register it as a proper Nextcloud storage.
Existing issues:
copyFromStoragedoes only check the storage ID and it is the same as this is only a transparent replacement and thus it most likely will fail when something is moved between appdata buckets or out of appdata bucket into another one.getObjectStoreis not covered and might randomly return one of the both instances (depending on what path was written/read from before)