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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
