Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dude]

ok, the corruptions do not happen so often to me as to him, but i have more than enough disk space, I.C.H. is enabled too but has recovered only 2 or three parts so far.
btw I'm using 1.2.4 self compiled with debian sid 2.4.22.

[werner]

I'm also seeing a very large number of corruptions with aMule 1.2.4.
With xMule, this number is considerably lower. (Which may of course
be simply related to aMule moving more data. I didn't count corruptions
vs. amout of data transferred.)

Anyway, here are a few ideas for how this could be improved:

- if *Mule currently offers data from not yet verified chunks for upload,
  it could stop doing so. That way, files spread more slowly, but
  more importantly, the spread of corruption is slowed even more.

- I think the recovery strategy is to discard the entire chunk, and
  to try again. It would be better to keep all downloaded parts,
  keyed either by origin or by transfer session. aMule could then
  try to combine fresh data with old data, to try to replace only the
  corrupt part.

- if implementing the above, one could also rate sources by how
  often/how much they contribute to producing a valid chunk. This
  rating should be considered experimental, because there are
  obviously several ways for subverting it.

- if data is keyed by origin, aMule could avoid asking sources for
  parts of unknown validity) it has already received from them.
  (Note: this assumes that data does not get corrupted during transfer.)

Keeping data of corrupt chunks around has the disadvantage that
disk space requirements increase unpredictably.

- Werner

[Kry]

Sorry man but there's a severe problem with the files you're downloading (you should reconsider, btw, not posting you're downloading copyrighted stuuf). If you do a global search of the names of the files, there are 1-2 results with lots of sources, then several dozens of 1 source elinks, which means the hash changed.

I really think is files related.

[stefanero]

I also had the same problem with my amule the last week. I downlaoded some fiel 4times the amount of data it should be. Still they did not finisch.
After that I was a little frustrated placed my temp files on another computer and created a FAT partition on my SuSE.
afer that I run my temp files again an now I have a normal amound of currupt parts, and my files finally finish. ole!
maybe the people who have problem with currupt parts should consider creating a fat partition, at least it helped for me  

stefanero

[Kry]

Hum. Then is ext2/3 related?

[stefanero]

could be I don't know friend of mine uses amule fine with ext3. he had no problems at all. :rolleyes:
but I have to say he did not let it run very long.   X(  he went back to windoof (german)
in the beginning I had no problems also with currupt parts, but say after a week or so the problems seamed to increase.
don't know, have a fat partition now and everythign runs just great

[emperor]

Originally posted by Kry
Hum. Then is ext2/3 related?

Maybe... I'm running it on JFS without any problems..

[werner]

One more data point: I recompiled aMule 1.2.4 with
--enable-debug --disable-optimise, I'm running it now under gdb,
and I seem to be getting considerably less corruption.

This smells like either a compiler or library problem (*), or some
other data corruption in aMule that only hits vital data under
certain circumstances.

(*) E.g. https://rhn.redhat.com/errata/RHSA-2003-325.htm

System configuration:
aMule      1.2.4
wxWindows   2.4.1
GTK         1.2.10
gcc         3.2 20020903 (Red Hat Linux 8.0 3.2-7)
libc         2.2.93
libstdc++      3.2 (libstdc++.so.5.0.1)
File system      ext3

I've added some instrumentation to track the relative frequency of
corruption. Patch attached. (It's for 1.2.4, but is offset by one line,
because of some other changes not relevant to the issue at hand.)

Output so far (that's for about four hours of relatively low traffic,
around Jan 23, 03-07 UTC, with an increase of on-disk data of
about  20-50 MB/h):

bad 1 good 0 ich 0 other 175
bad 2 good 5 ich 0 other 648
bad 3 good 6 ich 0 other 745
bad 4 good 10 ich 0 other 1026
bad 5 good 10 ich 0 other 1040
bad 6 good 10 ich 0 other 1047

(The last three occurred within 5 minutes between "bad 4" and
"bad 6". After that, things were quiet for 30 minutes, at which time
I stopped the test.)

- Werner

[werner]

aMule spit them out during shutdown:

bad 7 good 13 ich 0 other 1164
bad 8 good 16 ich 0 other 1177

Now preparing to run without gdb and default "configure"
settings.

- Werner

[werner]

(*) E.g. https://rhn.redhat.com/errata/RHSA-2003-325.htm

Obviously, RH don't use 8+3 names, so make that
https://rhn.redhat.com/errata/RHSA-2003-325.html

The potential problem is the one at
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90077

Sorry,
- Werner

[Kry]

Well, it does NOT happen on my side so it might not be code's fault... or maybe yes.

:/

[deltaHF]

like i said.. not aMule fault cos i should have then the prob too .. actually i have 1 or 2 corrupted parts / week ..

thx for tracking werner  

[werner]

Originally posted by deltaHF
like i said.. not aMule fault cos i should have then the prob too ..

We'll see :-) If it's some memory corruption caused by aMule,
environmental factors can make a huge difference. Likewise,
if there is any possibility for a race condition in the hashing
part.

Nothing interesting to report from the non-gdb run: traffic is
very slow this morning at ~9kB/h, and no corruption so far.

- Werner

[Kry]

There is 60% sure a memory corruption is happening on amule, and I'm tracking it

[werner]

A run without gdb, 5.5 hours, 08-13:30 UTC, 10-35 MB/h:

bad 1 good 2 ich 0 other 206
bad 2 good 4 ich 0 other 464
bad 3 good 5 ich 0 other 539
bad 4 good 6 ich 0 other 646

And during shutdown:

bad 5 good 8 ich 0 other 685

Now trying with a more recent glibc. (2.3.2-4.80.8 )

- Werner