Bug 1738786
Summary: | ctime: If atime is updated via utimensat syscall ctime is not getting updated | |||
---|---|---|---|---|
Product: | [Community] GlusterFS | Reporter: | Kotresh HR <khiremat> | |
Component: | ctime | Assignee: | Kotresh HR <khiremat> | |
Status: | CLOSED NEXTRELEASE | QA Contact: | ||
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | mainline | CC: | bugs, nchilaka | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | If docs needed, set a value | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1743627 1746138 1746142 (view as bug list) | Environment: | ||
Last Closed: | 2019-08-20 16:54:08 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1743627, 1746138, 1746142 |
Description
Kotresh HR
2019-08-08 07:38:54 UTC
REVIEW: https://review.gluster.org/23177 (ctime: Fix ctime issue with utime family of syscalls) posted (#1) for review on master by Kotresh HR Discussion at the patch which is worth mentioning here Kinglong Mee: @Kotresh HR, I cannot reproduce this problem as you description, Steps to Reproduce: touch /mnt/file1 stat /mnt/file1 sleep 1; touch -m -d "2020-01-01 12:00:00" /mnt/file1 stat /mnt/file1 Actual results: ctime is same between two stats above Expected results: ctime should be changed between two stats above I test at glusterfs mount and nfs mount, all get right result as, # sh test.sh File: file1 Size: 0 Blocks: 0 IO Block: 131072 regular empty file Device: 30h/48d Inode: 13578024673158818984 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2019-08-08 18:39:16.099467595 +0800 Modify: 2019-08-08 18:39:16.099467595 +0800 Change: 2019-08-08 18:39:16.100847925 +0800 Birth: - File: file1 Size: 0 Blocks: 0 IO Block: 131072 regular empty file Device: 30h/48d Inode: 13578024673158818984 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2019-08-08 18:39:16.099467595 +0800 Modify: 2020-01-01 12:00:00.000000000 +0800 Change: 2019-08-08 18:39:17.126800759 +0800 Birth: - --------------- Sorry, this is not happening with your patch[1]. Because we don't update ctime to mtime which was previously being done. But with your patch [1], I think all setattrs even some internal setattrs are updating ctime. So when file is created, all times should be same. But now it's not. [root@f281 glusterfs]# stat /mastermnt/file3 File: /mastermnt/file3 Size: 0 Blocks: 0 IO Block: 131072 regular empty file Device: 2eh/46d Inode: 13563962387061186202 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:fusefs_t:s0 Access: 2019-08-08 17:44:31.341319550 +0530 Modify: 2019-08-08 17:44:31.341319550 +0530 Change: 2019-08-08 17:44:31.342550008 +0530 <<<< ctime is different Birth: - [root@f281 So I was trying to fix this issue. And other thing, ideally updating atime|mtime should update ctime with current time, which was not happening in "posix_update_utime_in_mdata" but was happening as part of "posix_set_ctime" in posix_setattr. ----------------------------- |But with your patch [1], I think all setattrs even some internal setattrs are updating ctime. So when file is created, all times should be same. But now it's not. Yes, you are right. when file is created, all times should be same. With the patch[1], those times are different. For nfs, a create of a file, nfs client sends a create rpc, and a setattr(set time of server). Ganesha.nfsd gets the CLOCK_REALTIME for mtime/atime, and the utime xlator gets the realtime for ctime, so that, we cannot gets all times same when creating file. I think we should let utime xlator gets the realtime for all times(ctime/atime/mtime), ganesha.nfsd does not do that. |With this patch, it is clean. I am inclined to take this patch in if this solves the original nfs problem you reported. Could you please test that out and let me know? With this patch, the nfs problem of bad ctime is not exist now. [1] https://review.gluster.org/#/c/23154/ REVIEW: https://review.gluster.org/23177 (ctime: Fix ctime issue with utime family of syscalls) merged (#7) on master by Amar Tumballi |