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@xxxxxxxxxx>
To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
Sent: Tuesday, January 26, 2016 8:17:14 AM
Subject: 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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
