Print

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

[Stu Redman]

I think the intense hard disk usage during hashing in background is playing hell with the slow saving of the known file list in the foreground.
To fix this I propose to move the knownfiles->SafeAddKFile() and the knownfiles->Save() from CamuleApp::OnFinishedHashing() to CHashingTask::Entry(). Both are mutex-protected.
If SafeAddKFile() fails no event is posted.

Also switch from the hashed size trigger to a fixed time (like 5 min) to trigger a Save() . Timer becomes a member of CKnownFileList (remember last save/load).

So we will have

Code: [Select]

void CamuleApp::OnFinishedHashing(CHashingEvent& evt)
{
<unchanged>
if (owner) {
<unchanged>
} else {
sharedfiles->SafeAddKFile(result);
}
}

I can make a patch, but I don't like to commit this at the moment shortly before a release.

[Kry]

Yeah, definitely not for before a release.

Technically, hashed size IS a timer. If you take X time to hash every MB, you'll take X*Y to hash Y megabytes. The reason it's a hashed size counter is because this way it's consistent across small and big files,  except big files should only save when they finish. Small files will be saved when a bunch is done. This sounds like the optimal way to me, tbh.

[Stu Redman]

What you describe as optimal would still be the same. Only difference, on a fast system we save now more often than on a slow system. With the timer, it will just check after each hashed file if the last save was more than 5 min ago. If yes it will save. (Timer will be reset on each save, and before starting a rehash.)
The time spent feels like an easier to grasp quantity than the megabytes to me.

Anyway, the important part is saving the known.met in background. It really takes too long for a foreground activity with such large shares.

[stoatwblr]

This still leaves a window of opportunity for the file to be trashed by a SIGKILL or system crash while the old version is gone and new version isn't there.

[Stu Redman]

I've changed the write mode in 10620. It now writes to "known.met.new" and renames it after closing.
Though I still don't believe this will solve your actual problem. Still it's good practice.

[Stu Redman]

Better yet, use 10621.

[x_x_kamikaze_x_x]

Better yet, use 10621.

Upload it please to http://amule.sourceforge.net/tarballs/tarballs.xml   

[Stu Redman]

http://code.google.com/p/amule/source/checkout

(and that change is probably useless for you unless you have similar problems as stoatwblr)

[x_x_kamikaze_x_x]

http://code.google.com/p/amule/source/checkout
(and that change is probably useless for you unless you have similar problems as stoatwblr)

Thanks for the info! 
Don't worry, I know that but I always want to test the last version in order to
"check" all the new features! 

Hey, this change is very useful.
Please also consider applying write_safe to other critical or big files  (nodes.dat, key_index.dat for example).
Not everybody is running amule on  reliable, fast  systems. Dirty shutdowns, or OOM crashes, can happen .

I think the same!

[Stu Redman]

Please also consider applying write_safe to other critical or big files  (nodes.dat, key_index.dat for example).

Anybody else agree/disagree ?

[GonoszTopi]

nodes.dat: yes
*_index.dat: no

[stoatwblr]

Better yet, use 10621.

Works perfectly.

(I ran through a few crashes to verify all ok)

Thanks