HorseHockey
31st October 2006, 09:44 AM
Hope this isn't a FAQ, did a search and got a mess of hits on SHA1SUM. The titles that looked likely to be this issue didn't mention this problem.
Decided to save the main servers some bandwidth and try downloading FC6 with bittorrent instead of FTP/HTTP. Built a new P4 based system and loaded FC5 on it (passed checks). Ran updates with yum and it is up to date. Loaded bittorrent, Azureus and Transmission with Pirot. All three seem to work. Downloaded the DVD ISO. SHA1SUM said it's good. Cool! Downloaded the CD ISO's (one of the machines I want to load on doesn't have a DVD-ROM drive and I like to have compatible media "just in case") and 3 files didn't pass SHA1SUM. Weird. I thought the hash check was supposed to prevent that. I assumed that maybe the client wasn't doing that correctly. I was also concerned that I was seeding bad files. So as an experiment, I re-downloaded the first disk ISO file using a different client. SHA1SUM failed. As another experiment, I used HTTP and FTP to download two other Linux (not FC6) big binary files I wanted and both of those passed their check sums, so I don't think it's the system or a network problem.
So what is the protocol for bittorrent in this situation? I've read that if I reload the .torrent file it will make the client check all the hashes and supposedly fix the bad sections (although I wonder why that works because it didn't catch them with the hash check during the initial download). Should I keep seeding these files even though they might contain errors? I have a very stable upload connection that I was leaving seeding FC when it's idle, but I don't want to be smearing a problem around (so it's not seeding for now).
So... in summary:
Are corrupted download files that common (in this case 5 out of 6)? If not, any hints as to what is going wrong?
Is it true that if I reload the .torrent file the client will find the errors and fix them (rather than waste a ton of b/w redownloading the whole file)?
If I think a file is corrupt should I continue seeding it (I was starting the torrent and leaving it until the next day)? Or should turn that off until I reload the .torrent file and it passes SHA1SUM?
Of those bittorrent clients which one is the best for clean downloads and seeding (versus concentrating on fast downloads)? It seemed like bittorrent was the best compromise between features I needed and features I didn't really care about.
I run about thirty RHEL ES4 Linux servers, so although I'm not a total noob I am new to P2P.
Thanks!
-HH
P.S. I considered switching to Centos and decided against it because I use Fedora on a few systems that are non-production and used for trying the newest stuff. If something was more production-ish, then I'd just use another RHEL ES license and run something that was RH supported.
Decided to save the main servers some bandwidth and try downloading FC6 with bittorrent instead of FTP/HTTP. Built a new P4 based system and loaded FC5 on it (passed checks). Ran updates with yum and it is up to date. Loaded bittorrent, Azureus and Transmission with Pirot. All three seem to work. Downloaded the DVD ISO. SHA1SUM said it's good. Cool! Downloaded the CD ISO's (one of the machines I want to load on doesn't have a DVD-ROM drive and I like to have compatible media "just in case") and 3 files didn't pass SHA1SUM. Weird. I thought the hash check was supposed to prevent that. I assumed that maybe the client wasn't doing that correctly. I was also concerned that I was seeding bad files. So as an experiment, I re-downloaded the first disk ISO file using a different client. SHA1SUM failed. As another experiment, I used HTTP and FTP to download two other Linux (not FC6) big binary files I wanted and both of those passed their check sums, so I don't think it's the system or a network problem.
So what is the protocol for bittorrent in this situation? I've read that if I reload the .torrent file it will make the client check all the hashes and supposedly fix the bad sections (although I wonder why that works because it didn't catch them with the hash check during the initial download). Should I keep seeding these files even though they might contain errors? I have a very stable upload connection that I was leaving seeding FC when it's idle, but I don't want to be smearing a problem around (so it's not seeding for now).
So... in summary:
Are corrupted download files that common (in this case 5 out of 6)? If not, any hints as to what is going wrong?
Is it true that if I reload the .torrent file the client will find the errors and fix them (rather than waste a ton of b/w redownloading the whole file)?
If I think a file is corrupt should I continue seeding it (I was starting the torrent and leaving it until the next day)? Or should turn that off until I reload the .torrent file and it passes SHA1SUM?
Of those bittorrent clients which one is the best for clean downloads and seeding (versus concentrating on fast downloads)? It seemed like bittorrent was the best compromise between features I needed and features I didn't really care about.
I run about thirty RHEL ES4 Linux servers, so although I'm not a total noob I am new to P2P.
Thanks!
-HH
P.S. I considered switching to Centos and decided against it because I use Fedora on a few systems that are non-production and used for trying the newest stuff. If something was more production-ish, then I'd just use another RHEL ES license and run something that was RH supported.
