背景
我经常在 tmpfs（一个具有大量 RAM 的 Linux 系统）上排队下载很多种子文件，因为这些种子文件我不需要长期存储，只是为了在早上快速查看它们（那里不需要为此磨损磁盘）。 但是在早上我经常看到 tmpfs 分区已满（在 KDE Plasma Dolphin 中甚至声称文件占用的空间比分区的实际大小还多）并且下载速度为 0。最终结果是：很少（或没有）的种子实际上已经完成，尽管有足够的播种机并且许多文件肯定适合分区。 因此，除非我手动监控/处理此过程，否则我似乎无法真正拥有自动完成种子的顺序队列。
我的设置是：
最大活跃下载量 = 2
下载速率阈值 = 50 KiB/s
上传速率阈值 = 50 KiB/s
Torrent 不活动计时器 = 20 秒
当前（4.1.6）似乎无法找到一种方法告诉 QBT 如果目标分区上的空间不足，则不要启动（预分配）下一个 torrent 文件。 有这样的选择真的很有用。
想要支持这个问题？ 在上面发布赏金！ 我们通过Bountysource接受赏金。
emanruse
所有3条评论
无论您是否预先分配种子，这都应该适用。 也许可以有一个设置，如果可用空间小于 X 数量，则不要启动任何种子。 创建一个新状态，例如“等待”。 此外，如果您不预先分配它应该自动暂停正在下载的种子。
iheartcsharp
于 2019-05-15
也许可以有一个设置，如果可用空间小于 X 数量，则不要启动任何种子。
更好的：
“不要启动 torrent，这会导致磁盘可用空间小于 X”。
然后 QBT 将简单地移动到队列中的下一个（可能更小）并保持大的排队。 如果一个 torrent 被重新定位到另一个卷（或移动到一个类别），这给了它更多的空间，它将被重新评估为新的位置和相应的：保持排队或开始下载。
此外，如果您不预先分配它应该自动暂停正在下载的种子。
这可能会导致复杂性和混乱，因为对于许多种子来说，人们可能很难知道为什么某些内容会暂停并且无法恢复。 另外，我不太明白它如何与“强制恢复”一起使用。
仅在启用完整洪流预分配的情况下简单地使用请求的选项似乎要容易得多。
emanruse
于 2019-05-15
@emanruse
仅在启用完整洪流预分配的情况下简单地使用请求的选项似乎要容易得多。
为什么要限制它？ 预分配当前已损坏（请参阅#6195）。 我看不出这个选项只有在检查预分配时才可用的原因。 完成的 torrent 将在移动到另一个驱动器时释放空间，不仅是在预先分配它们时，而且在正常下载时也是如此。
JakubKoralewski
于 2020-02-23
相关问题
slrslr
·
3评论
klepp0906
·
3评论
X2LR
·
3评论
coolio2013
·
3评论
osgioia
·
4评论
最有用的评论
更好的：
“不要启动 torrent，这会导致磁盘可用空间小于 X”。
然后 QBT 将简单地移动到队列中的下一个（可能更小）并保持大的排队。 如果一个 torrent 被重新定位到另一个卷（或移动到一个类别），这给了它更多的空间，它将被重新评估为新的位置和相应的：保持排队或开始下载。
这可能会导致复杂性和混乱，因为对于许多种子来说，人们可能很难知道为什么某些内容会暂停并且无法恢复。 另外，我不太明白它如何与“强制恢复”一起使用。
仅在启用完整洪流预分配的情况下简单地使用请求的选项似乎要容易得多。