-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Work directly on the storage when uploading over webdav #12006
Conversation
Wow, sounds promising 😄 |
Hmm, thinking about it this currently bypasses encryption, either need to add some special case for it (yuk) or finally refactor encryption as a storage wrapper |
|
I'd vote against a special case - what would be the effort to implement encryption as a storage wrapper? @schiesbn what's your opinion on the encryption storage wrapper? @karlitschek @craigpg we should definitly invest some time to follow this path as this has a direct impact on the sync performance and opens up a path to solve chunked upload (in general and for external storage maybe - see #4997 (comment)) |
Note: moving encryption to a storage wrapper is likely to break a lot of stuff, as we need to make sure that all the numerous places that relied on hooks still works with the storage wrapper. This will need some research. @schiesbn what do you think ? We've struggled at lot to make encryption stable and avoid lots of bugs in special situations, so need to make sure these will still be there after the move. If the unit tests coverage we have now for encryption is broad enough, then it might help ensure this. |
@icewind1991 @schiesbn maybe raise a ticket to do the necessary research, but I feel like this is out of scope for OC8. |
increasing performance (including chunked upload performance and related issue in the area of the desktop client) are a goal for OC8 - this approach here looks really promissing and - as far as I can tell - is the basis for improving chunked upload - see #4997 (comment) But @PVince81 is right - this is a critical decision regarding encryption and we need @schiesbn and @icewind1991 collaborating on this |
I didn't had a detailed look at the storage wrapper yet. As far as I understand it it would replace the proxies. I think it depends how large the changes to the encryption code are. I don't want to risk any instability if it isn't absolutely necessary. Failures in encryption often results in data lose so I don't want to throw out code which matured over the last two releases airy. I'm also not sure if it is possible to write the chunks directly to the file. This would mean that the chunks needs to be encrypted on the fly and placed at the right spot. But encrypted files have a different size which is not linear across the file. So the uploaded chunks would need to match the chunk size we need for encryption or need to be a multiple of it. All probably doable, but I'm skeptical that we can do it for OC8 with the current time frame and the other stuff we have on the table. |
Requires adoption of encryption -> OC8.1 |
@schiesbn I think that the code I developed for #12909 has support for writing chunks to existing encrypted streams. The stream_write I wrote can definitely handle that; stream_open would have to be updated. Not sure how it would fit in with the storage wrapper suggested here. |
a48357a
to
6a59502
Compare
@icewind1991 @schiesbn rebased ... let's see |
@icewind1991 4 failung unit tests:
|
Jenkins: #15514 |
This would be super sweet to get in for 8.1 :-) |
@th3fallen @schiesbn @DeepDiver1975 So this now works with encryption 2.0? |
@icewind1991 Is this still WIP? Otherwise change the title and add the correct label ;) |
yes |
Let me know when you're done so I can retest and rereview. Thanks. |
Should be done given jenkins isn't sick today |
@icewind1991 give him his pills |
@@ -71,7 +71,7 @@ class File extends Node implements IFile { | |||
* different object on a subsequent GET you are strongly recommended to not | |||
* return an ETag, and just return null. | |||
* | |||
* @param resource $data | |||
* @param resource|string $data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you forgot to remove the comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
Uploads with cadaver, pyocclient test suite and sync client upload worked. 👍 |
A new inspection was created. |
@MorrisJobke @DeepDiver1975 please review |
Refer to this link for build results (access rights to CI server needed): |
👍 |
Work directly on the storage when uploading over webdav
Raised #15647 to do the same in chunking mode. This PR only affects files uploaded without chunking. |
Regression: folder size propagation doesn't happen any more: #18006 |
This this change improve performance significantly ? |
^ should make a difference - afaik we had a blackfire graph ... |
Was the benchmark done before or after fixing the regressions ? Maybe the correctFolder logic should be done asynchronously (and debounced) eventually. |
Not going trough the entire filesystem stack for the part files during uploading saves a good amount of work and database queries.
In my local test instance this saves 24 queries for a regular upload and 89 queries when uploading to a shared folder.
cc @DeepDiver1975 @PVince81