I have been testing the new 2.5.1p1 (I realize 2.5.1p2 has been released, but amindexd does not appear to have changed between these versions).

When attempting to use amrecover to browse an indexed backup of a large filesystem with 360,000 files, each browse operation (setdisk, cd, ls, etc) blocks for an extremely long time (significant fractions of an hour, 20 or more minutes at least). During this time, the amindexd process pegs the cpu.

My next smaller backup partition (in the same saveset and tape) contains about 160,000 files, so more than half of the number, and it takes amrecover less than a second to respond to each command.

This seems very strange. 160k files takes less than a seccond, yet not even twice as many files takes dozens of minutes?

If any of the developers are monitoring the list, can you shed some light on why this may be happening? Is this a bug?

Thanks.

Evan

Reply via email to