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" <[email protected]> To: "Gluster Devel" <[email protected]> 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 [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
