Benjamin Lewis wrote:
There is something which leap out at me as soon a I saw this: the kind of person who _needs_ atime, knows how to set it. The majority of people
- especially the home use - has little or no use for it whatsoever.
The majority of people will see a performance boost they will appreciate regardless of whether they know about atime or not.
But whether it is a noticeable difference or not will depend on the number of files they access, either with automated build procedures or GUI file managers that like to peek inside every file. People who keep their directory trees sparse and don't venture out of their home directory in a GUI much will probably not know the difference except that tmpwatch may not clean up correctly and their mailer may have to do more work to decide if a message is unread (etc.).
In my experience, viewing a folder of images as thumbnails is significantly slower with atime.
Are you sure that your viewer didn't cache the thumbnail images on the first run so you were timing something different after changing the option?
Many users will be viewing folders of images methinks. In addition, most GUIs read a large (read huge) number of files when they load, so load times for the GUI should be reduced also.
Some users will, some won't. The atime change should be going though the disk write cache and thus only have a real-time hit when there is enough disk activity that the cache writes conflict with read operations.