Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1773530

Summary:	ctime value is different from atime/mtime on a create of file
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
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:		Environment:
Last Closed:	2019-12-10 05:07:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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