Bug 1746138 - ctime: If atime is updated via utimensat syscall ctime is not getting updated
Summary: ctime: If atime is updated via utimensat syscall ctime is not getting updated
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: ctime
Version: 6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kotresh HR
QA Contact:
URL:
Whiteboard:
Depends On: 1738786 1746142
Blocks: 1743627
TreeView+ depends on / blocked
 
Reported: 2019-08-27 18:06 UTC by Kotresh HR
Modified: 2019-08-30 09:24 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1738786
Environment:
Last Closed: 2019-08-30 09:24:44 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Gluster.org Gerrit 23312 None Merged ctime: Fix ctime issue with utime family of syscalls 2019-08-30 09:24:43 UTC

Description Kotresh HR 2019-08-27 18:06:39 UTC
+++ This bug was initially created as a clone of Bug #1738786 +++

Description of problem:
When atime|mtime is updated via utime family of syscalls,
ctime is not updated.

Version-Release number of selected component (if applicable):
mainline

How reproducible:
Always

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

Additional info:

--- Additional comment from Worker Ant on 2019-08-08 07:43:19 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

--- Additional comment from Kotresh HR on 2019-08-20 10:49:58 UTC ---

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/

--- Additional comment from Worker Ant on 2019-08-20 16:54:08 UTC ---

REVIEW: https://review.gluster.org/23177 (ctime: Fix ctime issue with utime family of syscalls) merged (#7) on master by Amar Tumballi

Comment 1 Worker Ant 2019-08-27 18:11:22 UTC
REVIEW: https://review.gluster.org/23312 (ctime: Fix ctime issue with utime family of syscalls) posted (#1) for review on release-6 by Kotresh HR

Comment 2 Worker Ant 2019-08-30 09:24:44 UTC
REVIEW: https://review.gluster.org/23312 (ctime: Fix ctime issue with utime family of syscalls) merged (#2) on release-6 by hari gowtham


Note You need to log in before you can comment on or make changes to this bug.