Comment 1 Eric Warnke (reporter) 2008-08-06 04:29:57 UTC

Created an attachment (id=860) [details]
script to test for atime updates.

Comment 2 Eric Warnke (reporter) 2008-08-06 04:30:42 UTC

Keywords

Comment 3 Faheem Pervez 2008-08-06 19:00:49 UTC

*** This bug has been confirmed by popular vote. ***

Comment 4 Eero Tamminen 2008-08-11 16:11:53 UTC

This is marked as performance.  Is there some use-case where this is
actually measured to slow things down (and does VFAT implement atime)?

Comment 5 Eric Warnke (reporter) 2008-08-11 19:05:42 UTC

I will try to find a use case where this can be measured.  The problem is that
there must be both IO and CPU activity to really see the issue.  I would expect
to see the most difference on things like an initial media scan.

Either way it will reduce the wear and tear on flash drives as well.  I will
flash back to stock kernel and attempt to find a situation where the effect can
be measured.

Comment 6 Eric Warnke (reporter) 2008-08-12 22:17:40 UTC

I could not, reproducibly, demonstrate a performance drag despite my
understanding of atime.  I have removed the keyword and changes the title since
atime will create wear and tear on the mount point over time.

Comment 7 Eero Tamminen 2008-08-13 15:33:19 UTC

(In reply to comment #6)
> I could not, reproducibly, demonstrate a performance drag despite my
> understanding of atime.  I have removed the keyword and changes the title since
> atime will create wear and tear on the mount point over time.

Do FAT file system disk structures support atime (i.e. there anything kernel
could even write to card)?  I think it only has create/last modification
time...

Comment 8 Eric Warnke (reporter) 2008-08-13 18:35:23 UTC

vfat contains a adate field.  This means when loading or saving the inode the
precision is cut down to ~1day.  It is wildly inaccurate, but is kept
up-to-date in the vfs inode.  

See

fs/fat/inode.c

Since atime and inode dirty setting are part of the stock vfs the kernel will
happily continue to update atime and mark the inode dirty for writing on access
no matter if the atime change will actually result in an on device change to
the vfat structure.

see

include/linux/fs.h ( file_accessed )
fs/inode.c ( touch_atime )

These will touch the inode atime and mark the inode dirty despite the
inaccurate vfat atime field and the kernel will attempt to flush in good time. 
So not only are there write cycles to the block device.  Fat block semantics
also appear to require a 1-at-a-time inode write with kernel lock and sync
write ( fs/fat/inode.c ).

Comment 9 Eero Tamminen 2008-08-13 18:52:31 UTC

Thanks for checking this!

Additional writes could conceivably be also one reason why the FAT seems
sometimes to corrupt (e.g. as a result of crawler media file reading
causing card adate writes and user taking the card out while the writes
are in progress).

Comment 10 Eero Tamminen 2008-08-25 11:20:41 UTC

Will be fixed in next release (noatime+nodiratime).

As you've looked in to the kernel side, does the kernel still
provide with these option atime information to user-space while
the media is mounted (although the information then doesn't get
stored on the media)?

Comment 11 Frantisek Dufka 2008-09-01 11:39:09 UTC

As it is marked solved/fixed this is just for additional information

(In reply to comment #4)
> This is marked as performance.  Is there some use-case where this is
> actually measured to slow things down

This is just a feeling without any measurement and it could be even caused by
something else but if you open 'file open' dialog and open memory card view
(even just its root directory) with many directories with many files inside it
seems to scans directories recursively (just to display '+' overlay over folder
icon) and dialog gets unresponsive for some time at the beginning, then it is
OK and then it is again unresponsive after few seconds. Just try to quickly
open card and navigate 2 or 3 folders inside some tree hierarchy. You can
sometimes manage to do it quickly but if you are not fast enough you must wait
for next window of opportunity. Such scanning may cause lot of atime updates so
disabling it may cause dialog to be a bit more responsive.

One can guess it is atime updates by monitoring mmcqd kernel thread. It seems
to get pretty busy when writing but not when reading. So if one is just
scanning card and mmcqd gets busy something is not right.

Also start from this post
http://www.internettablettalk.com/forums/showthread.php?p=210260#post210260 to
see other performance issues, remounting with noatime helped

Another use case is metalayer-crawler, it touches a lot of files.

> (and does VFAT implement atime)?
> 

Yes people claim it does. Check some links in
http://www.internettablettalk.com/forums/showthread.php?p=210676#post210676

I think the nodiratime option is redundant (see
http://thread.gmane.org/gmane.linux.kernel/565148 and/or
http://lwn.net/Articles/244941/).

Comment 13 Eric Warnke (reporter) 2008-09-01 17:28:20 UTC

(In reply to comment #11)
> As it is marked solved/fixed this is just for additional information

You would be surprised how hard it is to quantify the problem in terms of real
world issues.  I even tried writing a mock file scanner and could not quantify
a difference.  It's possible that python is just not fast enough to quantify
the problem.

The benefits to wear and tear are the biggest, especially with the crawler
scanning the media on every boot.  There are probably subtle interactive issues
as well ( media playback was my example on iTT ).

Comment 14 Andre Klapper 2008-09-29 15:40:51 UTC

Fix included in today's 4.2008.36-5 update (ke-recv version 2.28-1).
Please verify if you find some time.

Both cards are now mounted noatime,nodiratime according to mount(8),
/proc/mounts & /etc/mtab:

/dev/mmcblk0p1 on /media/mmc2 type vfat
(rw,nosuid,nodev,noexec,noatime,nodiratime,uid=29999,fmask=0133,dmask=0000,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8)
/dev/mmcblk1p1 on /media/mmc1 type vfat
(rw,nosuid,nodev,noexec,noatime,nodiratime,uid=29999,fmask=0133,dmask=0000,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8)

and the attached test_atime.py agrees:

~ $ ./test_atime.py /var/tmp/
atime is NOT being updated, this is good
~ $ ./test_atime.py /media/mmc1
atime is NOT being updated, this is good
~ $ ./test_atime.py /media/mmc2
atime is NOT being updated, this is good

(I don't seem to have permission to change the status, sorry)