strictatime, not relatime #1917
Comments
|
Did you reimport the pool (or remount the filesystems) after setting the atime property? |
|
On Mon, 2 Dec 2013, Gregor Kopka wrote:
atime's always been set on most of my filesystems, so yes. Tim Connors |
|
@spacelama I don't quite understand. Currently ZFS only supports noatime and strictatime, I'd like to support relatime but noone has had the time to work on that yet. Could you perhaps post some example commands from your pool which show the issue? |
|
On Tue, 3 Dec 2013, Brian Behlendorf wrote:
I would have thought that relatime was handled by the VFS. And by having Anyway, atime being forgotten can be seen here: 130-0-17:51:08, Sun Dec 08 tconnors@fs:~/movies/kaffeine (bash) ie, file accesed before being fully downloaded. Let's access the fileagain now that it's finished: 0-0-17:51:10, Sun Dec 08 tconnors@fs:~/movies/kaffeine (bash) 0-0-17:51:16, Sun Dec 08 tconnors@fs:~/movies/kaffeine (bash) excellent, atime has been updated. Or has it? I've seen it forget theatime after a while before. So let's drop cache: 0-0-17:51:18, Sun Dec 08 tconnors@fs:~/movies/kaffeine (bash) 0-0-17:51:54, Sun Dec 08 tconnors@fs:~/movies/kaffeine (bash) nope, still good. Let's wait a bit after the disks have done lots ofactivity to really make sure the caches are cleared: 0-0-22:51:56, Sun Dec 08 tconnors@fs:~/movies/kaffeine (bash) bugger, still remembers the atime. Let's check it will still beupdated, given that relatime is documented as only bothering updates 0-0-23:00:24, Sun Dec 08 tconnors@fs:~/movies/kaffeine (bash) 0-0-23:00:50, Sun Dec 08 tconnors@fs:~/movies/kaffeine (bash) Well bugger that, let's wait another day:0-0-20:30:53, Mon Dec 09 tconnors@fs:~/movies/kaffeine (bash) 0-0-20:41:13, Mon Dec 09 tconnors@fs:~/movies/kaffeine (bash) Well, I'll be damned, it's gone back to the atime it originally knew 0-0-20:49:54, Mon Dec 09 tconnors@fs:~/movies/kaffeine (bash) 0-0-20:50:50, Mon Dec 09 tconnors@fs:~/movies/kaffeine (bash) 0-0-20:51:13, Mon Dec 09 tconnors@fs:~/movies/kaffeine (bash) Tim Connors |
|
There seem to be two problems here: First, as of 2.6.30, Linux defaults to relatime and in order to get "real" atime, a mount requires the MS_STRICTATIME option but, unfortunately, the mount.zfs program doesn't apply that option on post-2.6.30 kernels when atime=on. Second, the atime update (stored in the dnode's SA) is never synced back to the disk. @spacelama, your "wait a day" behavior is undoubtedly being caused by the metadata being aged out of the arc. You'll see the same thing if you simply umount/mount the file system. I'm going to try to run this down. My current theory is that it may have to do with 8780c53. As to the first issue, it seems we may need a change to the mount.zfs program and another configuration option. |
|
@dweeezil Once you start digging in to this you might find that it's relatively straight forward to implement support for relatime. It would be nice to have the support in place since I think it would be the right thing to default to. |
|
@behlendorf I was thinking the same thing. |
|
Quick update on this issue: I've gotten to the bottom of the problem and am researching the cleanest solution. The reason that atimes aren't updated after a read is because the zfs_inode_update() function used in zfs_read() re-looks-up all the timestamps from the SA which blows away anything that has been updated in the mean time [by zfs_tistamp_update_setup()]. I've got a trivial hack worked up that fixes zfs_read() but, as I mentioned, am looking for better solutions to deal with the atime issue and, possibly, the handling of the other timestamps. As to relatime, it'll be rather simple to implement but, again, I'm looking for a cleaner solution than to duplicate the logic within ZoL. The post-2.6.30 kernels provide the file_accessed() macro which does the Right Thing but it's not somthing we can easily used because of our non-use of inodes on-disk. XFS has the similar issues and I think was partially the reason for adding the update_time method to the kernel's inode_operations (which is something else I'd like to try to support in kernels that have the feature). Our lack of aio operations also works into these timestamp problems because it make is difficult to use more of the kernel's infrastructure. I'll be posting an initial patch tomorrow to address the immediate problem. |
|
@dweeezil Interesting, yes I can see how that could happen. If you have a relatively clean/trivial hack to fix this we might be able to live with that until we can do the right thing. And in my view the right long term thing is to eliminate the zfs_inode_update()` function. It was always just meant as a stop gap until the znode and inode could be properly unified. Although that's a much bigger change... Anyway, I'm looking forward to seeing your fix. |
|
@behlendorf I just posted my hack to make this work. I'm going to see if I can get relatime working now. The main problem I see is that the kernel stores the flags in the vfs where may be difficult to get ahold of them from the zfs code. Also, I can see that it's going to be easier to duplicate the relatime logic for the time being rather than trying to use more of the infrastructure provided by the kernel. |
Add the "relatime" property. When set to "on", a file's atime will only be updated if the existing atime at least a day old or if the existing ctime or mtime has been updated since the last access. This behavior is compatible with the Linux "relatime" mount option. Signed-off-by: Tim Chase <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#2064 Closes openzfs#1917
I don't know whether this is a documentation or an implementation issue, but there doesn't seem to be a way to disable relatime atime updates and revert back to traditional strictatime.
On pools that I've set atime=on, the kernel thinks everything is still mounted according to /proc/mounts (and actual behaviour) as relatime. How do I force strictatime semantics? Both for legacy mounts and zfs-mount mounts?
With ext4, you put strictatime in fstab, but when there's no fstab because it's handled by zfs, what's the option?
The text was updated successfully, but these errors were encountered: