>>/11182/
My system could basically handle everything ("checking resume data" completed) up until I changed the save paths to IPFS on about two of them, upping the torrents' total file count to half a million. Then it took too long and/or had other problems. For me, the "max" total file count of FUSE-mounted torrents is about a quarter of a million. I dropped it to be roughly 150,000 or 100,000 total to be faster.

With qBittorrent, there's like five main data things. (1). BitTorrent seed files: only one .torrent file per info hash, so in $HOME/.local/share/data/qBittorrent/BT_backup/ you can't have both the original and itorrents one. (2) Resume files: each .fastresume file in "BT_backup" contains info like save path and percent downloaded. Like TORRENT files, FASTRESUME files are bencoded and usually contain binary data. Each .fastresume file should contain the entirety of the info that the qBittorrent GUI tells you about each torrent, stats like how much was downloaded, amount uploaded, and share ratio. (3) Save path: whichever folder you picked to download the torrent to or whichever file or folder you picked when creating a torrent. (4) Logs: info logged in ./qBittorrent/logs/. (5) Session data in memory, which is accumulated into .fastresume files. Has info like how much was uploaded of a torrent while the current qBittorrent PID has been active/running. If you pause an uploading torrent then that resets how much you uploaded of that torrent for that session to zero in the GUI.

When "testing", I modified the save paths of those many-files torrents
> problem = it tries to check all 8 all at once [ >>/11182/]
by changing what was written in the FASTRESUME file for each of the eight:
$ read -p "cid: " c; read -p "infohash: " i; sed -i "s/$c/_$c/g" $i.fastresume
That did successfully change the paths to nonexistent ones, such as:
> qBt-savePath52:/ipfs/_QmWsSMs83bRJ5JVsPryR1sH4wMBL4ZB7eRqKhwjXwR7b4Q14
However, the unexpected thing is after doing that, I launched qBittorrent and those 8 torrents didn't show up at all. Don't know what the dealio is with that. Maybe sed changed other data in that binary file like a text editor might do (safer to have sed or vim edit plain text files which have no binary data). Maybe the bencoding became invalid somehow (like if there's a field which says the length of the save path). Maybe some other thing to "safeguard" qBittorrent when those files get edited by something external. IDK. Anyways, I have backups of those FASTRESUMEs, so it's "fine".

 >>/11156/
> 4.4 terabytes of torrents:
> /ipfs/QmWKGSSDn7C73NhCZPq1bCZDfEQstndLbgQoQz1QZGFnYH
That links to 99.9% complete "4chan_gif_2023_06.zip" torrent at
> ipfs://QmWcx1BhXu9TSNX5fNFvWC4hoxBWUUNv97H9pEqCwiESPm
The 100% complete version of that >60-GB file is here:
> ipfs://bafybeihwzrk2hihxvmkxopid64qrcndlwani3rdrln7sig6k2jrpgch7j4 [ <- "ipfs --offline add -rH --cid-version=1 --chunker=size-1048576 ." ]