From d9d2a0928204a91d02b599ff02aaad4b095aaac4 Mon Sep 17 00:00:00 2001 From: ed Date: Sun, 2 Feb 2025 23:22:06 +0000 Subject: [PATCH] mention fuse/rclone hijinks from #132 --- .github/ISSUE_TEMPLATE/bug_report.md | 1 + README.md | 2 ++ 2 files changed, 3 insertions(+) diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index cb723222..6a83bb57 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -29,6 +29,7 @@ if the issue is possibly on the server-side, then mention some of the following: * python version: * copyparty arguments: * filesystem (`lsblk -f` on linux): +* run copyparty with `--version` and copy the last 3 lines **Client details** if the issue is possibly on the client-side, then mention some of the following: diff --git a/README.md b/README.md index 8d080670..54f9521f 100644 --- a/README.md +++ b/README.md @@ -1579,6 +1579,8 @@ connecting to an aws s3 bucket and similar there is no built-in support for this, but you can use FUSE-software such as [rclone](https://rclone.org/) / [geesefs](https://github.com/yandex-cloud/geesefs) / [JuiceFS](https://juicefs.com/en/) to first mount your cloud storage as a local disk, and then let copyparty use (a folder in) that disk as a volume +if copyparty is unable to access the local folder that rclone/geesefs/JuiceFS provides (for example if it looks invisible) then you may need to run rclone with `--allow-other` and/or enable `user_allow_other` in `/etc/fuse.conf` + you will probably get decent speeds with the default config, however most likely restricted to using one TCP connection per file, so the upload-client won't be able to send multiple chunks in parallel > before [v1.13.5](https://github.com/9001/copyparty/releases/tag/v1.13.5) it was recommended to use the volflag `sparse` to force-allow multiple chunks in parallel; this would improve the upload-speed from `1.5 MiB/s` to over `80 MiB/s` at the risk of provoking latent bugs in S3 or JuiceFS. But v1.13.5 added chunk-stitching, so this is now probably much less important. On the contrary, `nosparse` *may* now increase performance in some cases. Please try all three options (default, `sparse`, `nosparse`) as the optimal choice depends on your network conditions and software stack (both the FUSE-driver and cloud-server)