The SLOOOWWW Inchworm

[jeroen]

I have also tried the 'sort by name' function, this works normally, it is the 'sort by last access' optimisation mode that is showing this issue every time it's run

Yes, that's what's so puzzling about it. The program code is exactly the same for both cases, except for a tiny little bit of code that compares two files (which file is "bigger"), depending on the selected sort method. If two files have the same date then it will compare the filenames. So I don't get it....

if you want the full log (up to where I stopped it) I can email it to you if you want

Yes, please! I need a bigger logfile. The snapshot and the first section of the logfile that you posted do not show me what the problem could be.

[JDPower]

if you want the full log (up to where I stopped it) I can email it to you if you want

Yes, please! I need a bigger logfile. The snapshot and the first section of the logfile that you posted do not show me what the problem could be.

Have emailed the d4 log from the run above to you and also sent (separately) the d6 log from a previous run, though I can't remember how much info is in that one.

[JDPower]

Hi Jeroen, I know you've been plenty busy with bug fixing lately but have you been able to work this one out? (not nagging, just curious )

[jeroen]

Hi Jeroen, I know you've been plenty busy with bug fixing lately but have you been able to work this one out? (not nagging, just curious )

I have looked at your logfile and I have looked at the sources, but I do not understand yet why the program can get in a loop. Sorry, but this is not an easily fixed problem, you may have to wait for some time before I have a fix...

[Lundholm]

I really don't think it is normal, like I said I moved all the files to the end of the disk before running the a9 option but it still created a worm of files at the start of the disk that slowly worked their way up, surely they should have just been placed at the right section with there being no files in the way. Also it took nearly 3 hours to process about 1% of the data, it normally completes in that time. I gave up on that and then ran the 'sort by name' option and this worked as expected (placing the files directly in place rather than worming up from the bottom) and was complete in under 2 hours.

If I get time I'll run it with the d6 debug level and post a section of the log (I'm not gonna run it till it finishes as it may take a day or more).

Re-reading this thread, I recognize the symptoms as identical to the ones I have reported on versions 3.24 and 3.25 in another thread. In my case, more or less all of zone 2 is moved upwards forever. I just don't have the patience to wait 3 hours for anything. I can reproduce this anytime on my system partition. The interesting thing is that version 3.16 works fine.

Jeroen, we have a problem. The -a 9 sort is the most important feature of Jkdefrag, in my opinion.

[Capsaicin]

Re-reading this thread, I recognize the symptoms as identical to the ones I have reported on versions 3.24 and 3.25 in another thread. In my case, more or less all of zone 2 is moved upwards forever. I just don't have the patience to wait 3 hours for anything. I can reproduce this anytime on my system partition. The interesting thing is that version 3.16 works fine.

Jeroen, we have a problem. The -a 9 sort is the most important feature of Jkdefrag, in my opinion.

I saw the same thing on my system with 3.24 (haven't tried 3.25) using -a 10 sort. 3.16 worked fine for me, too.