xfs-masters
[Top] [All Lists]

[Bug 857] access times disappear

To: xfs-masters@xxxxxxxxxxx
Subject: [Bug 857] access times disappear
From: bugzilla-daemon@xxxxxxxxxxx
Date: Sun, 15 Nov 2009 22:57:00 -0600
Auto-submitted: auto-generated
In-reply-to: <bug-857-113@xxxxxxxxxxxxxxxx/bugzilla/>
References: <bug-857-113@xxxxxxxxxxxxxxxx/bugzilla/>
http://oss.sgi.com/bugzilla/show_bug.cgi?id=857


Eric Sandeen <sandeen-xfs@xxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sandeen-xfs@xxxxxxxxxxx
         Resolution|                            |FIXED
            Summary|access times dissapear      |access times disappear




--- Comment #1 from Eric Sandeen <sandeen-xfs@xxxxxxxxxxx>  2009-11-15 22:56:58 
CST ---
Fixed by:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f9581b1443abac50c90168301d40a7734b13a5dc

From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 6 Oct 2009 20:29:26 +0000 (+0000)
Subject: xfs: implement ->dirty_inode to fix timestamp handling
X-Git-Tag: v2.6.32-rc6~49^2~7
X-Git-Url:
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=f9581b1443abac50c90168301d40a7734b13a5dc

xfs: implement ->dirty_inode to fix timestamp handling

This is picking up on Felix's repost of Dave's patch to implement a
.dirty_inode method.  We really need this notification because
the VFS keeps writing directly into the inode structure instead
of going through methods to update this state.  In addition to
the long-known atime issue we now also have a caller in VM code
that updates c/mtime that way for shared writeable mmaps.  And
I found another one that no one has noticed in practice in the FIFO
code.

So implement ->dirty_inode to set i_update_core whenever the
inode gets externally dirtied, and switch the c/mtime handling to
the same scheme we already use for atime (always picking up
the value from the Linux inode).

Note that this patch also removes the xfs_synchronize_atime call
in xfs_reclaim it was superflous as we already synchronize the time
when writing the inode via the log (xfs_inode_item_format) or the
normal buffers (xfs_iflush_int).

In addition also remove the I_CLEAR check before copying the Linux
timestamps - now that we always have the Linux inode available
we can always use the timestamps in it.

Also switch to just using file_update_time for regular reads/writes -
that will get us all optimization done to it for free and make
sure we notice early when it breaks.

Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Felix Blyakher <felixb@xxxxxxx>
Reviewed-by: Alex Elder <aelder@xxxxxxx>
Signed-off-by: Alex Elder <aelder@xxxxxxx>
---

I believe.  testing your script on .32 yields:

[root@inode mnt]# ./testit.sh 
+ dd of=foo seek=100000
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.3232e-05 s, 0.0 kB/s
+ mkdir bar
+ mkfs.xfs foo
meta-data=foo                    isize=256    agcount=2, agsize=6250 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=12500, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
+ mount foo bar -o loop
+ echo
+ umount bar
+ mount foo bar -o loop
+ ls -lu --fu bar/
total 4
-rw-r--r--. 1 root root 1 2009-11-15 22:50:54.644024953 -0600 a
+ sleep 2
+ cat bar/a

+ ls -lu --fu bar/
total 4
-rw-r--r--. 1 root root 1 2009-11-15 22:50:57.156024512 -0600 a
+ umount bar
+ mount foo bar -o loop
+ ls -lu --fu bar/
total 4
-rw-r--r--. 1 root root 1 2009-11-15 22:50:57.156024512 -0600 a
+ umount bar
+ rmdir bar
+ rm foo

If not feel free to reopen.

-- 
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

<Prev in Thread] Current Thread [Next in Thread>