Now I am trying to multi-thread where each thread will work on a fixed size set.

As Random_walk pointed out, splitting work in equal-sized chunks for threading is not a good strategy.

Some of your directories will contain less files than others, and some will contain only small files and others large files; so it is easy to see that some of your threads will finish more quickly than others which doesn't distribute the workload evenly.

A better approach would be to make the hash shared, and then queue the keys to the hash (the directory names) to a Thread::Queue and let the threads pick their work directories from there. Thus, the threads becomes self balancing.

That said, I have very profound doubts that threading your application will have any great benefit to your throughput if the directories you are backing up exist on a single physical volume. The problem is that if you have multiple threads (or processes) reading files concurrently from the same physical drive, you will likely create severe head-thrash and so, slow the overall throughput rather than increase it.

Even if your files are distributed across multiple spindles -- with SAS or raid or similar -- it is still dubious whether you will achieve huge benefits unless you could isolate the location of your files so that you could ensure that only one file from each physical unit was being read at any given time. Mostly, this is not possible as these multi-spindle setups tend to split files across multiple physical volumes transparently to the file system.