It's on the mds server (this is in 1.4.x)

/proc/fs/lustre/mds/.../atime_diff.



Lundgren, Andrew wrote:
> In my test cluster, I tried mounting with the noatime parameter.  It was not 
> supported for the client or the OSTs.
>
> You mention the largest performance gain below, did you change that yourself, 
> or did lustre change that with the install?  If you changed it, how high did 
> you set it?
>
> For our web server, we really don't care when the files were read, they will 
> be there anyway.  The atime info is not valuable to us at all, the writes are 
> just overhead.
>
> Thanks!
>
> --
> Andrew
>
>   
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> Adam Cassar
>> Sent: Tuesday, April 29, 2008 8:11 PM
>> To: '[EMAIL PROTECTED]'
>> Subject: Re: [Lustre-discuss] lustre and noatime option
>>
>>
>> The problem isn't with the RPC - its with the additional disk writes.
>>
>> The single lrgest metadata performance gain we achieved was
>> by changing
>> the atime_diff parameter in /proc
>>
>>
>> Brian J. Murrell wrote:
>>     
>>> On Tue, 2008-04-29 at 13:09 -0600, Lundgren, Andrew wrote:
>>>
>>>       
>>>> I don't need to know the last access time on my files.  I looked
>>>> though the manual, but didn't find a reference  to noatime.  Does
>>>> lustre use that setting? (on the cl
>>>>
>>>> --
>>>>
>>>> Adam Cassar
>>>> ICT Manager
>>>> NetRegistry
>>>> -------------------------------------------------------
>>>> o:  02 9699 6099
>>>> f:  02 9699 6088
>>>> d:  02 9641 8609
>>>> -------------------------------------------------------
>>>>
>>>> Netregistry Pty Ltd
>>>> www.netregistry.com.au
>>>> PO Box 270 Broadway, NSW 2007
>>>> tel: +61 2 9699 6099  fax: +61 2 9699 608
>>>> ient and/or server)
>>>>
>>>>         
>>> I don't believe it does because...
>>>
>>>
>>>       
>>>> On a file system that is read heavily, I would expect to see a
>>>> performance improvement by using that.  Is that true for lustre as
>>>> well?
>>>>
>>>>         
>>> Lustre already handles atime in a pretty efficient manner.
>>>       
>> Rather than
>>     
>>> disable it completely we update it "lazily".  What that
>>>       
>> means is that
>>     
>>> rather than sending immediate and explicit RPCs to update
>>>       
>> the atime we
>>     
>>> will delay sending them (for up to 5 seconds, tunable IIRC)
>>>       
>> and try to
>>     
>>> send atime updates "piggybacked" with other RPC traffic.
>>>
>>> b.
>>>
>>>
>>>
>>>       
>> --------------------------------------------------------------
>> ----------
>>     
>>> _______________________________________________
>>> Lustre-discuss mailing list
>>> [email protected]
>>> http://lists.lustre.org/mailman/listinfo/lustre-discuss
>>>
>>>       
>> --
>>
>> Adam Cassar
>> ICT Manager
>> NetRegistry
>> -------------------------------------------------------
>> o:  02 9699 6099
>> f:  02 9699 6088
>> d:  02 9641 8609
>> -------------------------------------------------------
>>
>> Netregistry Pty Ltd
>> www.netregistry.com.au
>> PO Box 270 Broadway, NSW 2007
>> tel: +61 2 9699 6099  fax: +61 2 9699 608
>>
>> _______________________________________________
>> Lustre-discuss mailing list
>> [email protected]
>> http://lists.lustre.org/mailman/listinfo/lustre-discuss
>>
>>     
> _______________________________________________
> Lustre-discuss mailing list
> [email protected]
> http://lists.lustre.org/mailman/listinfo/lustre-discuss
>
>   

-- 

Adam Cassar
ICT Manager
NetRegistry
-------------------------------------------------------
o:  02 9699 6099
f:  02 9699 6088
d:  02 9641 8609
-------------------------------------------------------

Netregistry Pty Ltd
www.netregistry.com.au
PO Box 270 Broadway, NSW 2007
tel: +61 2 9699 6099  fax: +61 2 9699 608

_______________________________________________
Lustre-discuss mailing list
[email protected]
http://lists.lustre.org/mailman/listinfo/lustre-discuss

Reply via email to