Ok I have worked all this day to find why *clunk* are still there time to time. And guess what! These clunks cannot be killed nor with DeClunk nor with ClunKiller_old.
I admit that the previous version of ClunKiller was not working nicely because I forgot to filter only the main hard drive activity, that means if you were watching a movie from an external USB drive *clunk* were still there. This has been fixed into this new 1.1 version.
Now the fact is that my application is analysing our hard drive activity to give the best solution to kill *clunk*. It's using a command called "sync" to wake the hard drive when it's idle. Why do I use this command? Because when the cache is flushed the following "sync" calls do not do anything on the drive but wake it. So the drive is no more making *tic* sounds referring to the writing command DeClunk or ClunKiller_old do. And because it does not write on the disk it does not shorten its life.
So this is what ClunKiller does when the drive is idle.
Now when the drive is not, ClunKiller does nothing to wake it, because it is not needed. Like I said, these *clunk* that happen time to time when the drive is writing/reading cannot be killed by a simple write/read on the disk so it is useless to slow your drive by thinking a write command can kill these *clunk*.
Now if you still think that writing on the disk every 4-5sec can kill all *clunk* noises I do not believe you because I tested it during 1hour by writing on the disk every 1sec using DeClunk! And I was able to hear some *clunk* when I launch some big apps such as itunes, Google Earth or also AppFresh.
It seems that *clunk* noises can also happen when a huge amount of data is wrote/read on the disk.
So now, I think, that killing these *clunk* noises only when it is needed is more powerful than a basic 5sec endless writing method.
I'm going to fix the deep sleep issue.