mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 21:35:58 +03:00
[GH-ISSUE #1311] s3fs error 400 due to part size exceeding 5GB #702
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#702
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 @xrefft on GitHub (Jun 19, 2020).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1311
To reproduce this problem,you just need:
or
Just copy a 5G file from local file system to s3fs.
Note: the maximum part size allowed by our s3 backend is 5GB.
@gaul commented on GitHub (Jun 19, 2020):
s3fs supports objects larger than 5 GB. How do you mount s3fs? Also which S3 server do you use?
Finally can you run via
s3fs -d -fand share the debug logs?@xrefft commented on GitHub (Jun 23, 2020):
S3fs does support 5GB files.
When the file grows slowly by
s3fs_write, everything is ok. But when the file grows fast bys3fs_truncate, it will be different.The error occurred when calling the
s3fs_truncatefunction.s3fs_truncatecallspagelist.Resize, andpagelist.Resizejust append one single large part into thepagelist.Next, when
RowFlushis called, the error happens naturally. Inside MultiPartUpload request, only 1 part will be uploaded.Our backend returns
Invalid Argumentonly, and we confirmed that the error is caused by too large Mutipart Size.@gaul commented on GitHub (Jun 23, 2020):
Thanks for the additional details! I can reproduce these symptoms locally. You can work around this with
-o nomixuploaduntil we create a fix for this.@xrefft commented on GitHub (Jun 24, 2020):
Thanks for your support!
Since we need to use s3fs, I tried to fix this bug in the code a few days ago, by trying:
1: append multiple (rather than one) part in the
InitandResizefunctions ofPageList.2: appropriate setting
is_modified=truewhen callingResizefunction.Obviously this increases the unnecessary memory usage. Looking forward to the official bug fixes!
@gaul commented on GitHub (Jun 24, 2020):
@ggtakec Any insight on this? I proposed a test based on @xrefft suggestion.
@ggtakec commented on GitHub (Jun 24, 2020):
@xrefft Thank you for reporting the defect.
and @gaul Thanks for the test code too.
I'm trying some tests on this subject.
Certainly there is a flaw in s3fs, but the problem was a bit more complicated than simple that I expected.
I have confirmed some case where the behavior of s3fs is different when I tried to upload a sparse file(which file had HOLE) created with truncate.
Even with a sparse file, I got different results depending on whether there are HOLEs in the whole file or partially.
I'll investigate the symptoms and make the patch code soon.
Thanks in advance for your help.
@xrefft commented on GitHub (Jun 24, 2020):
@ggtakec Since the
parse_partsize_fdpage_listfunction was added, our problem has been solved!Thank you very much!
@ggtakec commented on GitHub (Jun 24, 2020):
@xrefft It's glad for me, but I'm finding another problem(about sparse file), so I'll write a patchcord.
Thanks for your kindness.
@gaul commented on GitHub (Jun 24, 2020):
The referenced test still fails -- let's leave this open until we address that issue.
@ggtakec commented on GitHub (Jun 27, 2020):
@xrefft The fix code was merged into master.
I think this code solves the problem.
This issue will be closed, but if you still have problems, please reopen this.
Thanks.