Re: Calling stat with millions of files

[Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>]

Chris Mason wrote:
> On Tue, 2004-06-08 at 12:47, Hans Reiser wrote:
> 
>>really afford to do it just for you, sorry.
>>
>>>You'll get better results with the new block allocator in 2.6.7-rcX-mm,
>>>but in the end the stat information for the file isn't horribly close to
>>>the directory entries, and performance won't be perfect.
>>>
>>>Hans, I thought reiser4 was going to be good at this kind of thing?
>>>
>>>
>>
>>what in reiser4 optimizes accesses to hard links to files whose stat 
>>data is stored in other directories?  Maybe the stat data being stored 
>>near other stat data instead of near file bodies will help,.  Hmmm.  
>>Could be, have to try it to see.
> 
> 
> He said above that it creates hard links "when it can", not sure what
> percentage of the time this actually happens.

A good test for this would be

bk clone bk://linux.bkbits.net/linux-2.6
bk lclone linux-2.6 linux-test
# wait a few days for the repo to get out of sync
cd linux-2.6
bk pull

This should give you two trees which are only partially hardlinked and the
scenario should be halfway common for kernel developers.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/