[Gluster-devel] distributed files/directories and [cm]time updates

[Joseph Fernandes]

Addition case on ctime,

1. When we do internal operations like rebalance, tier-migration, afr-heal etc ctime time changes, this is not desirable as its a internal fop
2. For a compliance case(WORM-Retenetion), ctime change means there is something that has changes on a READ-ONLY file, which is be a point of concern. 

I agree with you on the overhead of booking keep of this xattr and sync between bricks and will add to the random access of the disk.
Also there is a window where we can get inconsistent, i.e ctime has changed as a result of a normal fop and before we get to save it in the xattr brick goes down.
Well this situation can be handled with replication sync however. Just thought of bring it to notice.

~Joe
  
----- Original Message -----
From: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
To: "Gluster Devel" <gluster-devel at gluster.org>
Sent: Tuesday, January 26, 2016 8:17:14 AM
Subject: [Gluster-devel] distributed files/directories and [cm]time updates

hi,
       Traditionally gluster has been using ctime/mtime of the 
files/dirs on the bricks as stat output. Problem we are seeing with this 
approach is that, software which depends on it gets confused when there 
are differences in these times. Tar especially gives "file changed as we 
read it" whenever it detects ctime differences when stat is served from 
different bricks. The way we have been trying to solve it is to serve 
the stat structures from same brick in afr, max-time in dht. But it 
doesn't avoid the problem completely. Because there is no way to change 
ctime at the moment(lutimes() only allows mtime, atime), there is little 
we can do to make sure ctimes match after self-heals/xattr 
updates/rebalance. I am wondering if anyone of you solved these problems 
before, if yes how did you go about doing it? It seems like applications 
which depend on this for backups get confused the same way. The only way 
out I see it is to bring ctime to an xattr, but that will need more iops 
and gluster has to keep updating it on quite a few fops.

Pranith
_______________________________________________
Gluster-devel mailing list
Gluster-devel at gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel