[Lustre-discuss] Slow performance on the first IOR / iozone (Lustre)

[Oleg Drokin]

Hello!

    You are certainly not obliged to do i/os to force bitmaps, since  
lustre will continue to work,
    it just will bear some penalties before all caches are populated.
    You certainly can prefetch that data sooner as a workaround and  
with zero kernel hacking
    required by e.g. doing dumpe2fs on every device with lustre  
backend fs after lustre servers
    are started (it is important to do this after mount, since kernel  
discards all block device data
    on last device close).
    I am not aware of any place in /proc where you can track current  
status of fs-specific cached
    metadata, also it might change over time, e.g. for fs that is not  
used, blocks might be forced
    out of memory.

Bye,
     Oleg
On Mar 25, 2008, at 5:37 AM, Cédric Lambert wrote:
> Hello,
>
> I am not today a kernel hacker ;-) and I would like to understand  
> something :
> Does it mean that when Lustre client is mounted, I am obliged to  
> make any IOs to force bitmaps cache or am I obliged to wait a  
> certain time before making any writes ? If Yes, can I monitor under / 
> proc this info ?
>
> Thanks
> Cédric
>
>
> Oleg Drokin a écrit :
>>
>> I believe what you are seeing is a direct result of bitmap blocks   
>> being not
>> read at mount time. So it takes some time to cache bitmaps (And other
>> data structures) into memory
>> (and it happens during writes which hinders performance).
>> Once bitmaps are all read, performance stabilizes.
>>
>> Hopefully Alex or Andreas might comment further on this, or  
>> perhaps  remember
>> a bug number, Cray filed one some time ago, I think.
>>
>> Bye,
>>     Oleg
>>