rather than sending each file chunk as a separate HTTP request, sibling chunks will now be fused together into larger HTTP POSTs which results in unreasonably huge speed boosts on some routes ( `2.6x` from Norway to US-East, `1.6x` from US-West to Finland ) the `x-up2k-hash` request header now takes a comma-separated list of chunk hashes, which must all be sibling chunks, resulting in one large consecutive range of file data as the post body a new global-option `--u2sz`, default `1,64,96`, sets the target request size as 64 MiB, allowing the settings ui to specify any value between 1 and 96 MiB, which is cloudflare's max value this does not cause any issues for resumable uploads; thanks to the streaming HTTP POST parser, each chunk will be verified and written to disk as they arrive, meaning only the untransmitted chunks will have to be resent in the event of a connection drop -- of course assuming there are no misconfigured WAFs or caching-proxies the previous up2k approach of uploading each chunk in a separate HTTP POST was inefficient in many real-world scenarios, mainly due to TCP window-scaling behaving erratically in some IXPs / along some routes a particular link from Norway to Virginia,US is unusably slow for the first 4 MiB, only reaching optimal speeds after 100 MiB, and then immediately resets the scale when the request has been sent; connection reuse does not help in this case on this route, the basic-uploader was somehow faster than up2k with 6 parallel uploads; only time i've seen this |
||
---|---|---|
.. | ||
handlers | ||
hooks | ||
mtag | ||
dbtool.py | ||
partyfuse-streaming.py | ||
partyfuse.py | ||
partyfuse2.py | ||
partyjournal.py | ||
prisonparty.sh | ||
README.md | ||
u2c.py | ||
unforget.py | ||
up2k.sh |
u2c.py
- command-line up2k client (webm)
- file uploads, file-search, autoresume of aborted/broken uploads
- sync local folder to server
- generally faster than browsers
- if something breaks just restart it
partyjournal.py
produces a chronological list of all uploads by collecting info from up2k databases and the filesystem
- outputs a standalone html file
- optional mapping from IP-addresses to nicknames
partyfuse.py
- mount a copyparty server as a local filesystem (read-only)
- supports Windows! -- expect
194 MiB/s
sequential read - supports Linux -- expect
117 MiB/s
sequential read - supports macos -- expect
85 MiB/s
sequential read
filecache is default-on for windows and macos;
- macos readsize is 64kB, so speed ~32 MiB/s without the cache
- windows readsize varies by software; explorer=1M, pv=32k
note that copyparty should run with -ed
to enable dotfiles (hidden otherwise)
also consider using ../docs/rclone.md instead for 5x performance
to run this on windows:
- install winfsp and python 3
- add python 3.x to PATH (it asks during install)
python -m pip install --user fusepy
python ./partyfuse.py n: http://192.168.1.69:3923/
10% faster in msys2, 700% faster if debug prints are enabled:
pacman -S mingw64/mingw-w64-x86_64-python{,-pip}
/mingw64/bin/python3 -m pip install --user fusepy
/mingw64/bin/python3 ./partyfuse.py [...]
you could replace winfsp with dokan, let me know if you figure out how
(winfsp's sshfs leaks, doesn't look like winfsp itself does, should be fine)
partyfuse2.py
- mount a copyparty server as a local filesystem (read-only)
- does the same thing except more correct,
samba
approves - supports Linux -- expect
18 MiB/s
(wait what) - supports Macos -- probably
partyfuse-streaming.py
- pretend this doesn't exist
mtag/
- standalone programs which perform misc. file analysis
- copyparty can Popen programs like these during file indexing to collect additional metadata
dbtool.py
upgrade utility which can show db info and help transfer data between databases, for example when a new version of copyparty is incompatible with the old DB and automatically rebuilds the DB from scratch, but you have some really expensive -mtp
parsers and want to copy over the tags from the old db
for that example (upgrading to v0.11.20), first launch the new version of copyparty like usual, let it make a backup of the old db and rebuild the new db until the point where it starts running mtp (colored messages as it adds the mtp tags), that's when you hit CTRL-C and patch in the old mtp tags from the old db instead
so assuming you have -mtp
parsers to provide the tags key
and .bpm
:
cd /mnt/nas/music/.hist
~/src/copyparty/bin/dbtool.py -ls up2k.db
~/src/copyparty/bin/dbtool.py -src up2k.*.v3 up2k.db -cmp
~/src/copyparty/bin/dbtool.py -src up2k.*.v3 up2k.db -rm-mtp-flag -copy key
~/src/copyparty/bin/dbtool.py -src up2k.*.v3 up2k.db -rm-mtp-flag -copy .bpm -vac
prisonparty.sh
- run copyparty in a chroot, preventing any accidental file access
- creates bindmounts for /bin, /lib, and so on, see
sysdirs=