Yeap, do let me know if the TMPDIR variable fixes torrenting problems.

Thanks for testing.

[cF] Checksum computation failed: Exception: write failed: No space left on device

to:

[cF] Checksum computation failed: Exception: lseek failed: Invalid argument

but this “invalid argument” message i get even if I use the symlinking the temp method, so it seems now at least that the exporting the TMPDIR variable is doing the same thing that my symlinking is, as to comparing the error messages…

I have to monitor this a bit closely if the TMPDIR-variable is enabling me to complete my torrents also, i’m hopeful that it will, so i’ll get back to you when i have completed some torrents

Edit mlnet.sh and add the following line under the current export statement in the shell script
export TMPDIR=”/mnt/HD_a2/mldonkey/temp”

Do let me know if it works

so adding smb restart after the linking and everything works just fine.

btw. i’m running the linking as the first thing in the fun_plug, so dropbear ssh and all the other fun_plug stuff from fonz gets started to the new tmp-directory…

rm -rf /mnt/HD_a2/tmp/*
cp -a /tmp/* /mnt/HD_a2/tmp/*
mv /tmp /tmp-bak
ln -s /mnt/HD_a2/tmp /tmp

in the fun_plug, i think a minimal damage is done since the swap is taking a very short time when done in a script. also the content of the original tmp is copied to the linked tmp, so any process needing the info gets it from the new place..

I don’t know why my system needs this, but it works. Otherwise everything is stuck to 99%…

I can see that there could be some danger if some process tried to write to tmp at the time i’m copying and moving the folder, but haven’t had any problems yet… *fingers crossed*…

max_opened_connections 192
max_indirect_connections 30
max_upload_slots 3
max_release_slots 20
max_connections_per_second 4

also tried to play around with buffers etc, but to no effect, the checksum calculation is failing due to not enough space.

In normal condition and mldonkey running my /ram0 73% in use, 2.5MB available however… it doesn’t seem to change when calculating the checksum, or maybe i haven’t been fast enought to type df -h

So far, the only solution for me has been symlinking the tmp to the hard-drive… which has worked for me perfect… i’m now in the process of adding the symlinkg to the fun_plug, so we’ll see if it’s ok..

I was also hoping for later to maybe chrooting debian and maybe have all the extras installed to a usb-key so that my both hard-drives could sleep while accessing for example my ssh, but i found out that if i have twonkey-media server on and it does it’s refresh hourly, during that refresh the usb-storage.ko module dies and attached drive is “dead” to the kernel…

Found this out when i was trying to move my data over external usb-enclosure, and the transfer stopped always after one hour. after killing twonkey, all worked…

I think i have to use the symlinking method for now, since I don’t yet know what parameters are crucial… of course i could just drop the download.ini directly to my box and try that, but i prefer tweaking the settings by hand… the problem is, that i don’t fully understand the mlnet parameters, and specifically what is causing this problem… i think i have all the settings now at a lower level than your samples, if i haven’t missed anything…

Is there any specific values i should check, which might influence to the computation error? However, i have only 73% in use all the time anyway, and still the computation error… maybe in multi-gigabyte transfers the chunk sizes are so big that the tmp-data does not fit into 2.5MB?