[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Disabling atime



n0dalus wrote:
> On 8/22/07, Eric Sandeen <esandeen redhat com> wrote:
>> As far as I'm concerned, nobody has done the necessary legwork to
>> justify this change.
>>
>> I have at least one case where noatime actually slows things down.  With
>> 66 million inodes on an ext3 filesystem, "find" across the filesystem
>> with a fresh mount / cold cache was a few seconds slower with noatime.
>> Odd result, but it shows at least that this change shouldn't be made
>> based on a hunch, but only after looking at some real results.
>>
>> -Eric
>>
> 
> Find will not benchmark atime, as it doesn't open the files for
> reading. 

It will update the atime of the dirs it reads.

[esandeen neon ext4]$ stat /tmp | grep Access | grep -v Uid
Access: 2007-08-21 12:56:16.582910381 -0500
[esandeen neon ext4]$ find /tmp > /dev/null
[esandeen neon ext4]$ stat /tmp | grep Access | grep -v Uid
Access: 2007-08-21 12:56:56.762072721 -0500

I know it's a strange test for atime, but it did seem to have a
detrimental effect on this particular workload (think updatedb).

Yes, there are certainly better tests, and I'm not saying "find" is a
definitive test for noatime, it was more of a curiosity.

I am saying, people who want this should prove the gains they claim.
Thanks for posting your numbers :)

-Eric


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]