mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 13:26:00 +03:00
[GH-ISSUE #1685] Parallel Multipart Upload failed because of Content Length 0 #875
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#875
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @CarstenGrohmann on GitHub (Jun 18, 2021).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1685
I've a simple copy job. The
cpcommand reports an IO error for setting timestamps. The file content is correct.When I follow the log entries, I see that setting the timestamps triggers a multipart upload. This upload fails. In doing so
cpreportspreserving times for "/s3mnt/3750M": Input/output error.But at the end, the flush command also triggers a multipart upload and this second upload is successful.
The difference between the two multipart uploads is: the first upload uses the
x-amz-copy-source-rangeheader but does not provide any content (Content-Length: 0) and the second upload does not usex-amz-copy-source-rangebut the correctContent-Length:.Additionally, I wonder why the final multipart upload does not set the correct times in the initial post request as shown in
step 7?Steps to reproduce:
Start s3fs
Copy a larger file
Content is correct but the timestamp is wrong
Detailed analysis:
file has fully written to the temporary file
timestamps will be set:
this triggers a multipart upload
Uploading part 1 is failing because of
Content-Length: 0This repeats for part 1 to 8 serveral times till the upload will be cleaned upload
the timestamp operation from step 2 finally fails
finally the temporary file will be flushed successfully, the
Content-Lengthheader is set correctly@CarstenGrohmann commented on GitHub (Jun 18, 2021):
Maybe this is a logical bug in
github.com/s3fs-fuse/s3fs-fuse@1e0e2752bf/src/s3fs.cpp (L1971)Starting this line as reported in the debug log:
github.com/s3fs-fuse/s3fs-fuse@1e0e2752bf/src/s3fs.cpp (L2051-L2061)The source looks like that the metadata will be updated on a non-existing object with
put_headers(is_copy=true):github.com/s3fs-fuse/s3fs-fuse@1e0e2752bf/src/s3fs.cpp (L2062-L2069)This probably causes the copy requests with
Content-Length: 0as shown in step 4:@ggtakec commented on GitHub (Jun 20, 2021):
@CarstenGrohmann I fixed the code and post PR about it.
If you are not sorry to trouble you, please check it.
@CarstenGrohmann commented on GitHub (Jun 20, 2021):
@ggtakec Thank you for the fast fix. I'll test the change as well as testcase tomorrow and share the feedback.
@ggtakec commented on GitHub (Jun 21, 2021):
@CarstenGrohmann Thanks for your feedback( https://github.com/s3fs-fuse/s3fs-fuse/pull/1689#issuecomment-864745558 )
This Issue has been resolved and will be closed.