n0dalus wrote: > On 8/22/07, Eric Sandeen <esandeen@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
