Stanislas @[email protected]

I guess I forgot I had a blog...

@breizh de même

"asynchronous disk I/O" by the dev of libtorrent (the one used by qBT, not the rTorrent one) in 2012: https://blog.libtorrent.org/2012/10/asynchronous-disk-io/

*laughs in NVMe RAID 0*

This doesn't matter for light usage, but on a big dedicated server and hundreds of torrents, it's another story

Transmission seem to use threads, but not has extensively has qBT.

threads seem to be the key... looks like rTorrent has a long way to go
- https://github.com/rakshasa/rtorrent/issues/1009
- https://github.com/rakshasa/rtorrent/issues/1010
- https://github.com/rakshasa/rtorrent/issues/1006
- https://github.com/rakshasa/rtorrent/issues/1011

I'll see how qBT does over the span of a couple of days, but for now it's much better than everything I used before in terms of performance

I only bumped the async i/o threads to 32 (from 10) because I have 32 cores. I uses more RAM (~8 GB) but I have 96 so it's fine...

it's much faster, the web UI/API doesn't struggle a bit

ok so I moved all my torrents from rTorrent to qBT on my actual seedbox, it's night and day

@alex @aspie4K then private trackers are the go-to

@aspie4K indefinite (I mean until someone decides to change the pricing model I guess but that's not planned afaik )

@aspie4K this is in the free tier:
- 75 GB of storage
- 75 GB of cold storage (GLACIER)
- 75 GB egress
- ∞ egress to scaleway services in the same region
- ∞ ingress
- ∞ requests

https://github.com/userdocs/qbittorrent-nox-static

Visualize Go process metrics in real-time https://nakabonne.dev/posts/gosivy/

@aspie4K indeed, a CDN can't hurt

@aspie4K You can't use two object storage providers at the same time on Mastodon, FYI

@aspie4K (disclaimer: I work at scaleway on object storage)