-
Notifications
You must be signed in to change notification settings - Fork 181
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
Cells-sync 0.9.2 doesn't trigger multipart uploads proprerly with a Cells v4 server and fails at 5GB using an S3 backend #433
Comments
Reading the Amazon S3 FAQ, this doesn't seem to be specific to Wasabi, but the expected behavior of an S3-compatible API. |
Hi @jqueuniet are you uploading the file through the web interface? It should use multipart by default, did you change any values in the upload options? |
I uploaded using the desktop client cells-sync, tried with both the Linux and Windows ones. I haven't tried web uploads, as they seemed to be discouraged for heavy uploads. The server is configured for multipart between the client and the server. Multipart threshold is at 100MB, and the part size at 50MB. This specific error message seems to originate from the S3 backend though, not the Pydio Cells server, as Pydio didn't have any upper limit configured for file size and the 5GB limit seems to be an S3 API one. |
I'm also getting this error message repeatedly during uploads in the server logs, not sure if this is important or not.
|
By the way, I had an open question related to big file uploads, namely where the chunks uploaded by the client to the Pydio server are temporarily stored before being sent, if they are stored at all and not immediately forwarded as S3 multipart chunks to the S3 backend. Currently, I allocated a 10GB Kubernetes PV for the Pydio working directory |
Hello, |
Thanks for the pointers. I tried doing an upload using the web interface and it did work as intended, so cells-sync is the most likely culprit. I'm using cells-sync release version 0.9.2, as the log above showed. Trying again using the Windows client, I get the following logs client-side about halfway though the upload, when the 5GB threshold is reached:
Server-side, this is the application log at abort time:
The error mentioned in my first message only appears in the container output, not in the application logs as recorded in the web UI. |
Hi Johann can you try with the last dev builds of cells-sync ? See https://download.pydio.com/pub/cells-sync/dev/ |
Hi, Using this new build, the upload goes farther on Windows, about 3/4 of the way but still gets cancelled before the end. The cells sync logs look like this:
On the server side, the only related log left is a warning related to encryption when the upload starts:
I'll try later with the Linux client and take a look at the container logs, can't do that from Windows. |
Getting the same behaviour with the Linux client, container logs didn't have anything of interest aside from the fact log lines with 200 chunks are long enough to make k9s choke when text is unwrapped. Since encryption was mentioned, I tried turning it off on the personal bucket, then all of them, but nothing changed. |
hi again, did you retry all that with the recent v4 ? |
Hello, tried again this morning using cells v4.0.1 and the latest cells-sync dev snapshot, still the same issue. I can now see the S3 error in the cells-sync logs though.
I'm using Traefik as ingress controller, not aware of any significant file size or timeout restrictions. |
damn, that one shows that you (?) downgraded the cells-sync version as it does not switch to multipart |
My cells-sync version is one of the latest dev snapshot.
|
I also get this error in cell-sync, but only when WebView was successfully forked in its own window.
When the fork fails and the web UI is loaded in the web browser instead, I don't get any message like this, The upload fails in both cases. |
I'm running into troubles using big files with an S3-compatible storage backend, namely Wasabi. My uploads get discarded with the following error message if they weight more than 5GB:
Reading the Wasabi doc, 5GB seems to be the threshold where their S3 API is expecting multipart uploads rather than single PUT operations: https://wasabi-support.zendesk.com/hc/en-us/articles/115001684511-What-are-the-minimum-and-maximum-object-sizes-that-can-be-stored-in-Wasabi- (they actually recommend multipart starting at 100MB file sizes).
I'm currently using Pydio Cells 4.0.0-rc5, in a Kubernetes setup described more in-depth here: https://forum.pydio.com/t/broken-setup-in-kubernetes-500-502-ws-xhr-errors/4691
The text was updated successfully, but these errors were encountered: