
如何把 S3 等云存储挂载成本地盘作为 copyparty 卷并调整 io 缓冲区提升传输速度【免费下载链接】copypartyPortable file server with accelerated resumable uploads, dedup, WebDAV, SFTP, FTP, TFTP, zeroconf, media indexer, thumbnails all in one file项目地址: https://gitcode.com/GitHub_Trending/co/copypartycopyparty 没有内建对 S3 等云存储作为卷的支持官方给出的做法是先用 FUSE 软件rclone、geesefs 或 JuiceFS把云存储挂载成本地盘再让 copyparty 把该磁盘上的一个目录作为卷使用。这篇文章完整走这条路径挂载云存储 → 把挂载点配置为卷并试验sparse/nosparsevolflag → 调大--iobuf/--s-rd-sz/--s-wr-sz→ 用实际传输对比选出组合。适用前提是你已有可用的 copyparty单文件版copyparty-sfx.py或安装后的copyparty命令均可并且系统支持 FUSE 挂载。把 S3 等云存储挂载为本地目录README 在 using the cloud as storage 一节明确copyparty 没有内建支持需要先挂载。文档点名的 FUSE 方案有三种rclonegeesefsJuiceFS任选其一按该工具自己的文档把云存储的某个桶挂载到一个本地目录本文用/mnt/s3表示这个挂载点下文命令中出现时请替换为你实际的挂载路径。挂载后有一个已知的访问问题如果 copyparty 无法访问 rclone/geesefs/JuiceFS 提供的本地目录比如目录看起来隐形README 给出的处理方式是给 rclone 加--allow-other运行和/或在/etc/fuse.conf中启用user_allow_other。文档中给出的实测参考值文档示例非固定预期有人测试 geesefs 配合 gocryptfs在 gbit 线路上得到 60 MiB/s 上传速度JuiceFS 使用内建加密时以 80 MiB/s 胜出。把挂载点配置为 copyparty 卷并试验 sparse 选项卷的语法是-v src:dst:perm把挂载点映射为 Web 根目录并设为任何人可读python copyparty-sfx.py -v /mnt/s3::r对于 S3 后端存储README 和 cfg.py 给出了两个与 sparse 文件相关的 volflagsparse强制使用 sparse 文件文档描述为 mainly for s3-backed storagenosparse禁止使用 sparse 文件文档描述为 mainly for slow storage两者的历史与现状README 原文要旨在 v1.13.5 之前官方推荐用sparse强制允许多个 chunk 并行曾把上传速度从1.5 MiB/s提升到80 MiB/s以上但风险是可能触发 S3 或 JuiceFS 的潜在 bugv1.13.5 增加了 chunk-stitching 之后sparse的重要性已大大降低反过来nosparse在某些情况下反而可能提升性能。README 的结论是三种都要试default、sparse、nosparse最优选择取决于你的网络条件和软件栈FUSE 驱动与云服务商两端都算。volflag 以:c,形式追加在卷定义后面README FAQ 中的同类示例是-v [...]:c,hist/tmp/foo# 禁止 sparse 文件 python copyparty-sfx.py -v /mnt/s3::r:c,nosparse # 强制 sparse 文件 python copyparty-sfx.py -v /mnt/s3::r:c,sparse可选调整默认情况下每个卷内部会创建.hist目录存放索引、缩略图等如果你不想把这些数据写到 S3 上可以用--hist全局选项或histvolflag 把它指到本地磁盘。如果你习惯用配置文件而不是命令行参数可参考 docs/example.conf 的格式全局选项写在[global]段。调大 io 缓冲区--iobuf / --s-rd-sz / --s-wr-sz针对云存储这条路径README 有两处明确的调优建议云存储一节you may improve performance by specifying larger values for --iobuf / --s-rd-sz / --s-wr-szperformance 一节卷位于 NFS / SMB / s3 这类网络盘时调大--iobuf和/或--s-rd-sz和/或--s-wr-sz可能有帮助尝试把三者都设为524288、1048576或4194304与前面的 volflag 试验组合起来一条完整的试验命令如下/mnt/s3替换为你的挂载点缓冲区三个值按上面三档逐档替换python copyparty-sfx.py -v /mnt/s3::r:c,nosparse \ --iobuf 524288 --s-rd-sz 524288 --s-wr-sz 524288需要留意docs/bufsize.txt 是开发者针对不同场景文件夹打包 tar/zip 下载、HTTP(S) 单文件下载、PUT/POST 大文件上传测试各种缓冲区大小的记录文档示例。结论是最优值随场景变化例如 zip 下载在默认--iobuf 262144时最优而某些场景偏好更大或更小的值——所以文档才要求你按自己的实际负载试验而不是照抄一个固定值。如何判断当前组合是否合适文档没有给出固定的成功日志或判定阈值判断方式是实际的传输对比挂载点可见启动 copyparty 后能通过卷的 URL 浏览到云存储里的目录和文件。若目录隐形或访问不到按上文加--allow-other或在/etc/fuse.conf启用user_allow_other。sparse 三选一default、sparse、nosparse各跑一轮真实的上传/下载比较速度保留最快的。缓冲区档位默认值、524288、1048576、4194304三者同时设置各跑一轮同样以实测速度为准。已知限制README 说明云存储卷在默认配置下probably get decent speeds但很可能受限于每个文件只走一条 TCP 连接上传客户端无法并行发送多个 chunk——这正是sparse选项存在的背景。最终组合没有通用答案README 原文把选择权留给读者最优值取决于网络条件与软件栈FUSE 驱动加云服务商并欢迎有实验结果的人把发现分享出来补充文档。【免费下载链接】copypartyPortable file server with accelerated resumable uploads, dedup, WebDAV, SFTP, FTP, TFTP, zeroconf, media indexer, thumbnails all in one file项目地址: https://gitcode.com/GitHub_Trending/co/copyparty创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考