I keep my var folder, home, etc on one single, root partition. If the root drive is full, Deluge loses track of ALL torrents and is a real PITA re-hashing everything from scratch. This has happened to me on THREE separate occasions:
- First time this happened was because I forgot to set the download folder, and it downloaded to the user folder by default.
- The second time was because I misconfigured logrotate and I slowly (but steady) ended up with huge logs which filled up the root drive.
- The third time was when I reinstalled a virtual machine and I forgot to change the VirtualBox snapshot folder.
It's killing my HDD, guys! Come on! Firefox doesn't lose tabs when this happens. On the other hand, it doesn't start either until you free up some space... Why can't Deluge do something similar?
If the drive is full, Deluge loses track of ALL torrents!
Re: If the drive is full, Deluge loses track of ALL torrents
if deluge filled your partition with logs i guess you should consider getting bigger hdd?
Re: If the drive is full, Deluge loses track of ALL torrents
No, the issue was that logrotate didn't compress them and iptables was logging every single fricken connection from every single website (plus ads), deluge connections, xchat connections, etc. There were like 300+ MB files, each, in /var/log/. Now I have that under control (I think). I set it to 100 MB max, and compressed.
But that's not the issue. A bigger root partition wouldn't solve the problem if a program goes haywire and fills it up or something. Worst case scenario I would rather have Deluge crash instead of abusing the HDD like that (a Hitachi that makes a ton of noise).
But that's not the issue. A bigger root partition wouldn't solve the problem if a program goes haywire and fills it up or something. Worst case scenario I would rather have Deluge crash instead of abusing the HDD like that (a Hitachi that makes a ton of noise).
Re: If the drive is full, Deluge loses track of ALL torrents
I have run out of hard drive space before but don't think I've seen this issue however I know there are two open tickets that would fix this problem so it will be sorted. The main one is seed mode that will enable you to tell Deluge that the torrents do not need checking.
Re: If the drive is full, Deluge loses track of ALL torrents
Let's hope it will be enabled by default.Cas wrote:The main one is seed mode that will enable you to tell Deluge that the torrents do not need checking.
Right now I'm guessing Deluge uses just one file with all the hashes for all the torrents. And if it can't write to it, the seeding progress for each and every single torrent goes back to zero.
Oh, and torrents that have been renamed (different folder name), start downloading with their default name included in the torrent release, even though I have ALREADY downloaded it under a different name.
For instance if I change the name of the folder from "House.S08E05.720p.HDTV.X264-DIMENSION" to "House 8 x 05", it starts downloading "House.S08E05.720p.HDTV.X264-DIMENSION" even though I already have it downloaded as House 8 x 05. You know what I'm saying?
So it doesn't lose just the seeding progress. It forgets I renamed some of the folders too. For larger torrents it could mess with the ratio if the re-hashing was left unsupervised (it would start downloading them by default).
Re: If the drive is full, Deluge loses track of ALL torrents
I just realised, from what you said, that I did not run into any issues on my server because it has a separate partition for the OS and applications so data using up too much space will not affect the config or state file.
There is a main state file and a fastresume one that store name mappings and torrent state so if anything happens to them then there is no way to determine what values to send to libtorrent when starting the application again.
This means that the other ticket about warning or pausing all torrent when disk is low does apply however I now realise there is another component to it that will need to also check the drive the state file is stored on.
Seed mode only will help if you have all the data for seeding so will not help for partially downloaded torrents if your state file is corrupt or missing.
I think you have just been unlucky finding the same bug through different circumstances.
There is a main state file and a fastresume one that store name mappings and torrent state so if anything happens to them then there is no way to determine what values to send to libtorrent when starting the application again.
This means that the other ticket about warning or pausing all torrent when disk is low does apply however I now realise there is another component to it that will need to also check the drive the state file is stored on.
Seed mode only will help if you have all the data for seeding so will not help for partially downloaded torrents if your state file is corrupt or missing.
I think you have just been unlucky finding the same bug through different circumstances.
Re: If the drive is full, Deluge loses track of ALL torrents
Sounds about right. But don't pause all the torrents. If Deluge can't write to those two files, freeze all torrents with a "Suspended (Low Disk Space)" message (so that they don't mix with the torrents that were paused before the disk ran out of space).Cas wrote:There is a main state file and a fastresume one that store name mappings and torrent state so if anything happens to them then there is no way to determine what values to send to libtorrent when starting the application again.
This means that the other ticket about warning or pausing all torrent when disk is low does apply however I now realise there is another component to it that will need to also check the drive the state file is stored on.
Seed mode only will help if you have all the data for seeding so will not help for partially downloaded torrents if your state file is corrupt or missing.
Hmmm... Should I add this to the Development section as a feature request? Or is it already on the way, in a similar form?
Re: If the drive is full, Deluge loses track of ALL torrents
You can update ticket #1899 with those details.Hmmm... Should I add this to the Development section as a feature request? Or is it already on the way, in a similar form?