Thanks for the mention :>
Yeah, copyparty was my attempt at solving this issue - a single python-file for receiving uploads of infinitely large files, usually much faster than other alternatives (ftp, sftp, nextcloud, etc.) especially when the physical distance to the uploader is large (hairy routing).
I’m not gonna put an upload on my site, that’s a security nightmare waiting to happen.
curious to hear your specific concerns on this; maybe it’s something that’s already handled?
You may encounter some confusing errors with MergerFS; depending on your config, any software using SQLite may crash with a scary-sounding “disk I/O error”. The quickstart has more info, https://trapexit.github.io/mergerfs/quickstart/
for a selfhosted service which is a single self-contained process in a single container, is there still a benefit to using compose, and if so, what would that be? genuine question since I’m not providing a compose example for a foss service I made.
Not proxmox-specific, but I’ve been using btrfs on my servers and laptops for the past 6 years with zero issues. The only times it’s bugged out is due to bad hardware, and having the filesystem shouting at me to make me aware of that was fantastic.
The only place I don’t use zfs is for my nas data drives (since I want raidz2, and btrfs raid5 is hella shady) but the nas rootfs is btrfs.
You could always toss it in a sandbox for some isolation :> but yeah I get you, all of the optional features does mean more code.
It’s a shame that browsers make stuff like chunked uploading so tricky, so even just the essentials would be a fair bit of logic – and you won’t get optimal upload speeds without sending chunks in parallel. And the corruption detection is also worth its weight in gold… Ah well, it is what it is hehe