Description of problem: On a fuse client, when a file was read immediately after writing into the file, the atime wasn't updating. This issue wasn't seen when md-cache was turned off. The issues was not seen when a sleep interval between the operations was set. Version-Release number of selected component (if applicable): 3.3.0qa27 How reproducible: Consistently Steps to Reproduce: 1. echo 'abc' >> " + /mnt/file 2. for i in `seq 100`; do cat /mnt/file; done 3. stat /mnt/file Actual results: STAT OUTPUT AFTER WRITES File: `/mnt/hello' Size: 8 Blocks: 8 IO Block: 131072 regular file Device: 14h/20d Inode: 12846742335012350422 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2012-03-12 03:42:53.282306434 -0400 Modify: 2012-03-12 03:42:53.289177283 -0400 Change: 2012-03-12 03:42:53.289177283 -0400 STAT OUTPUT AFTER READS File: `/mnt/hello' Size: 8 Blocks: 8 IO Block: 131072 regular file Device: 14h/20d Inode: 12846742335012350422 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2012-03-12 03:42:53.282306434 -0400 Modify: 2012-03-12 03:42:53.289177283 -0400 Change: 2012-03-12 03:42:53.289177283 -0400 Expected results: Stat after read should have the updated atime.
The culprit is not md-cache, but its quick-read. Since reads are served by quick read, reads wont hit backend resulting in non-updation of atime. If this consistency is really required, we can bring an update-atime kind of option (as present in read-ahead, which will update just atime on backend by doing a zero byte read in background) in quick-read too. Closing this bug as of now. Please re-open if its necessary.
Hi Raghu, all other performance translators were disabled here. Only md-cache was enabled. But with --direct-io-mode=on, it worked as expected.