Bug 1773530 - ctime value is different from atime/mtime on a create of file
Summary: ctime value is different from atime/mtime on a create of file
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: ctime
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kotresh HR
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-18 11:23 UTC by Kotresh HR
Modified: 2019-12-10 05:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-10 05:07:49 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Gluster.org Gerrit 23719 None Merged ctime: Fix ctime inconsisteny with utimensat 2019-12-10 05:07:48 UTC

Description Kotresh HR 2019-11-18 11:23:22 UTC
This bug was initially created as a copy of Bug #1761932

I am copying this bug because: 



Description of problem:
==================
with ctime feature, ctime/mtime/atime must be consistent on a file create.

However the ctime is slightly different from mtime/atime


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

How reproducible:
==========
always

Steps to Reproduce:
==================
1.create 1x3 volume , enable features.ctime, mount volume
2. touch a file say "f1"
3. do a stat of "f1"

[root@dhcp47-105 atime]# stat ctime
  File: ‘ctime’
  Size: 0         	Blocks: 0          IO Block: 131072 regular empty file
Device: 26h/38d	Inode: 10974573272318328388  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:fusefs_t:s0
Access: 2019-10-15 21:27:49.739915387 +0530
Modify: 2019-10-15 21:27:49.739915387 +0530
Change: 2019-10-15 21:27:49.740912036 +0530 -----> ctime different from a/mtime
 Birth: -



Addition info:
==============
While, I don't see any implication of the above, however this was to be fixed with ctime feature. 
Don't know if there could be any implication or race conditions or a minute window of causing unexpected issues.

Comment 1 Worker Ant 2019-11-18 11:29:19 UTC
REVIEW: https://review.gluster.org/23719 (ctime: Fix ctime inconsisteny with utimesat) posted (#1) for review on master by Kotresh HR

Comment 2 Worker Ant 2019-12-10 05:07:49 UTC
REVIEW: https://review.gluster.org/23719 (ctime: Fix ctime inconsisteny with utimensat) merged (#3) on master by Amar Tumballi


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