I've fixed the issue for myself by deleting the offending torrent, but it's a bug in transmission. Something worth noting is that the same torrent passed verify multiple times and verifying it will always say it's at 100%, so transmission things that the file is okay, while apparently being different in size. If writable is false and the size check fails, then it will try to call ftruncate on a file that isn't opened.
The only codepath that can cause such an event of calls is in fdlimit.c / cached_file_open: Pwrite() // on the file (bad file descriptor) Open() // on a file from that torrent in read-only modeįtruncate() // on that file, which failed with invalid argument (as expected) The problem is that Bad file descriptor is reported on downloading torrents, which are unrelated to the torrent that's causing the issue. More feedback on the issue: I strace'd transmission and it turns out that a single torrent in seeding mode was causing downloads to fail. T00:24:16.662524+02:00 localhost transmission-daemon: Error while flushing completed pieces from cache (session.c:539) If this condition is not triggered the downloaded amount is generally extremely close to the actual size. If I also set some to 'low priority', or otherwise further starve them for bandwidth, it is not at all unlikely to see 10x downloaded after 24 hours. Double the torrent size is not at all uncommon when I have observed this condition. If 'too many' simultaneous downloads are in process, transmission is reporting considerable extra 'Downloaded', with no explanation. I re-verified with no issue, and as soon as this completed, a peer with 99% connected, no data transferred however, and the peer disconnected.įinally, as some of these issues result in extra download, I note one more issue that seems to have manifested in recent versions, but definitely prior to 2.22: Tr_fdFileCheckout failed for : Invalid argument (inout.c:127) The problem torrents had not reported an error though.Ĭhecking the log of this client, I notice yet another error I do not recall seeing before.Ī specific older torrent that had been seeding for many months was filling the log with I only found the torrents missing data when I verified all after seeing a few 'failed verification' errors. I do not think the files were modified by a different process, because the bad chunks are completely zeroed out in the cases I checked. I mention this here, because it does not seem to be an underlying problem, as only specific torrents lost data, but those lost multiple chunks in every case. Rarely, a torrent is reporting a piece failed verification, but when I check it, nothing is missing.Īlso, a small amount of seeded data has vanished. The second issue seems similar enough to possibly be related, so I include it here too. Occasionally, this error follows, in the log:Įrror while flushing completed pieces from cache (session.c:532) The current torrent with this issue does not have extremely long path, it stops every few minutes with 'Bad file descriptor' for some random file, but can simply be restarted, with no issue evident, maybe a piece is lost. I run transmission-daemon on Ubuntu 10.04 though.
I have seen this issue on a small number of torrents, certainly less than 5%. It is possible that some are specific to my configuration, but I have seen some similar comments, so I will summarise some strange, but rare issues I have seen lately. I see that 2.30 is being prepared, so I must report some problems that I think are new to 2.22.
0 kommentar(er)
