[GH-ISSUE #1020] rsync issue large files #560

New issue

Closed

opened 2026-03-04 01:46:45 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 01:46:45 +03:00

Owner

Originally created by @DigitalCyberSoft on GitHub (Apr 25, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1020

This is from the latest built version of s3fs

# rsync -avW --inplace --progress largefile.tsv.gz /mnt/Data\ Mining/Stuff/2009/
sending incremental file list
largefile.tsv.gz
  7,051,300,017 100%   18.30MB/s    0:06:07 (xfr#1, to-chk=0/1)
rsync: failed to set times on "/mnt/Data Mining/Stuff/2009/largefile.tsv.gz": Input/output error (5)

sent 7,053,021,623 bytes  received 165 bytes  11,275,814.21 bytes/sec
total size is 7,051,300,017  speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1189) [sender=3.1.3]

There are two files in the same folder that have the same issue. This causes future rsync's to download the file and compare it, which is of course not wanted. The problem does not occur with any of the smaller files in the directory.

Is there a reason s3fs wouldn't be able to set the appropriate stats on a large file, but handle small files correctly?

Originally created by @DigitalCyberSoft on GitHub (Apr 25, 2019). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1020 This is from the latest built version of s3fs ``` # rsync -avW --inplace --progress largefile.tsv.gz /mnt/Data\ Mining/Stuff/2009/ sending incremental file list largefile.tsv.gz 7,051,300,017 100% 18.30MB/s 0:06:07 (xfr#1, to-chk=0/1) rsync: failed to set times on "/mnt/Data Mining/Stuff/2009/largefile.tsv.gz": Input/output error (5) sent 7,053,021,623 bytes received 165 bytes 11,275,814.21 bytes/sec total size is 7,051,300,017 speedup is 1.00 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1189) [sender=3.1.3] ``` There are two files in the same folder that have the same issue. This causes future rsync's to download the file and compare it, which is of course not wanted. The problem does not occur with any of the smaller files in the directory. Is there a reason s3fs wouldn't be able to set the appropriate stats on a large file, but handle small files correctly?

kerem closed this issue

2026-03-04 01:46:45 +03:00

kerem commented

2026-03-04 01:46:45 +03:00

Author

Owner

@DigitalCyberSoft commented on GitHub (Apr 25, 2019):

Some other similar issues for large files:

rsync: failed to set times on "/mnt/data/gtld/csvs.com.simple.tar.gz": Input/output error (5) rsync: ftruncate failed on "/mnt/data/gtld/out/com.gz": Operation not permitted (1) rsync: failed to set times on "/mnt/data/gtld/out/com.gz": Input/output error (5)

@DigitalCyberSoft commented on GitHub (Apr 25, 2019): Some other similar issues for large files: `rsync: failed to set times on "/mnt/data/gtld/csvs.com.simple.tar.gz": Input/output error (5) rsync: ftruncate failed on "/mnt/data/gtld/out/com.gz": Operation not permitted (1) rsync: failed to set times on "/mnt/data/gtld/out/com.gz": Input/output error (5) `

kerem commented

2026-03-04 01:46:46 +03:00

Author

Owner

@DigitalCyberSoft commented on GitHub (Apr 27, 2019):

Related error. Race condition for large files perhaps?

[INF]       curl.cpp:CopyMultipartPostSetup(3759): copying... [from=/output.txt.gz][to=/output.txt.gz][part=21]
[INF]       curl.cpp:CompleteMultipartPostRequest(3470): [tpath=/output.txt.gz][parts=21]
[ERR] curl.cpp:CompleteMultipartPostRequest(3481): 1 file part is not finished uploading.

@DigitalCyberSoft commented on GitHub (Apr 27, 2019): Related error. Race condition for large files perhaps? ``` [INF] curl.cpp:CopyMultipartPostSetup(3759): copying... [from=/output.txt.gz][to=/output.txt.gz][part=21] [INF] curl.cpp:CompleteMultipartPostRequest(3470): [tpath=/output.txt.gz][parts=21] [ERR] curl.cpp:CompleteMultipartPostRequest(3481): 1 file part is not finished uploading. ```

kerem commented

2026-03-04 01:46:46 +03:00

Author

Owner

@gaul commented on GitHub (Jul 9, 2019):

To me it looks like one of the multipart transfers failed despite retrying. Debug logs -d -d -o curldbg would help confirm this.

FWIW I successfully rsynced a large modified file, actually different Linux kernels with the same name, using 1.85:

$ cp ~/linux-5.1.tar files/linux.tar
$ rsync -avW --inplace --progress files/linux.tar mnt/
sending incremental file list
linux.tar
    871,659,520 100%  312.15MB/s    0:00:02 (xfr#1, to-chk=0/1)

sent 871,872,424 bytes  received 35 bytes  5,268,111.53 bytes/sec
total size is 871,659,520  speedup is 1.00

$ cp ~/linux-5.2.tar files/linux.tar
$ rsync -avW --inplace --progress files/linux.tar mnt/
sending incremental file list
linux.tar
    871,229,440 100%   17.08MB/s    0:00:48 (xfr#1, to-chk=0/1)                                                                                                                                                                                           sent 871,442,240 bytes  received 35 bytes  4,240,595.01 bytes/sec
total size is 871,229,440  speedup is 1.00

@gaul commented on GitHub (Jul 9, 2019): To me it looks like one of the multipart transfers failed despite retrying. Debug logs `-d -d -o curldbg` would help confirm this. FWIW I successfully rsynced a large modified file, actually different Linux kernels with the same name, using 1.85: ``` $ cp ~/linux-5.1.tar files/linux.tar $ rsync -avW --inplace --progress files/linux.tar mnt/ sending incremental file list linux.tar 871,659,520 100% 312.15MB/s 0:00:02 (xfr#1, to-chk=0/1) sent 871,872,424 bytes received 35 bytes 5,268,111.53 bytes/sec total size is 871,659,520 speedup is 1.00 $ cp ~/linux-5.2.tar files/linux.tar $ rsync -avW --inplace --progress files/linux.tar mnt/ sending incremental file list linux.tar 871,229,440 100% 17.08MB/s 0:00:48 (xfr#1, to-chk=0/1) sent 871,442,240 bytes received 35 bytes 4,240,595.01 bytes/sec total size is 871,229,440 speedup is 1.00 ```

kerem commented

2026-03-04 01:46:46 +03:00

Author

Owner

@gaul commented on GitHub (Feb 3, 2020):

Closing due to inactivity. Please reopen if symptoms persist.

@gaul commented on GitHub (Feb 3, 2020): Closing due to inactivity. Please reopen if symptoms persist.

kerem referenced this issue

2026-03-04 02:01:00 +03:00

[PR #560] [MERGED] Fixed about multipart uploading at no free space related to #509 #1550