To summarise the proposed solutions of the open issues,
1) For changelog xlator to have snapshot consistent, consumable changelogs (ie., those that are rotated), it needs to
block unlink/rename/rmdir FOPs in their call path, drain in-flight operations and ensure that the to be rotated changelog
has the corresponding changelog entries, before acknowledging to glusterd that the brick is ready to be snapshotted.
2) The solution for the inconsistency problem in a pure distribute problem is to be solved at server xlator's resolver code,
where dentry operations on a given dentry are serialized. This is to be solved independent of barrier xlator.
Feel free to add things that the summary fails to capture.
thanks,
Krish
From: "Anand Avati" <address@hidden>
To: "Vijay Bellur" <address@hidden>
Cc: "Krishnan Parthasarathi" <address@hidden>, "Anand Avati" <address@hidden>, "Raghavendra Gowdappa" <address@hidden>, "Varun Shastry" <address@hidden>, "Pranith Kumar Karampuri" <address@hidden>, "Venky Shankar" <address@hidden>, "Kaushal M" <address@hidden>, "Rajesh Joseph" <address@hidden>, "Kotresh Hiremath Ravishankar" <address@hidden>, address@hidden
Sent: Friday, March 7, 2014 12:21:54 AM
Subject: Re: [Gluster-devel] Barrier design issues wrt volume snapshot
FOPs that are still coming through after enabling barrier (assuming that barrier is done in the call path) would end up in a non-consumable changelog. For these operations, geo-rep would resort to FS crawl based on xtime which does not handle unlinks and renames.