<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    We are thinking different approaches to add support in
    Geo-replication for Sharded Gluster Volumes[1]<br>
    <br>
    <div class="ace-line" id="magicdomid731"><span
        class="author-g-6mby7anhycxlsw8t b"><b>Approach 1: Geo-rep: Sync
          Full file</b></span></div>
    <div class="ace-line" id="magicdomid132"><span
        class="author-g-6mby7anhycxlsw8t">   - In Changelog only record
        main file details in the same brick where it is created<br>
      </span></div>
    <div class="ace-line" id="magicdomid223"><span
        class="author-g-6mby7anhycxlsw8t">   - Record as DATA in
        Changelog whenever any addition/changes to the sharded file</span></div>
    <div class="ace-line" id="magicdomid321"><span
        class="author-g-6mby7anhycxlsw8t">   - Geo-rep rsync will do
        checksum as a full file from mount and syncs as new file</span></div>
    <div class="ace-line" id="magicdomid443"><span
        class="author-g-6mby7anhycxlsw8t">   - Slave side sharding is
        managed by Slave Volume</span></div>
    <div class="ace-line" id="magicdomid446"><span
        class="author-g-6mby7anhycxlsw8t">   </span></div>
    <div class="ace-line" id="magicdomid750"><span
        class="author-g-6mby7anhycxlsw8t b"><b>Approach 2: Geo-rep: Sync
          sharded file separately</b></span></div>
    <div class="ace-line" id="magicdomid552"><span
        class="author-g-6mby7anhycxlsw8t">   - Geo-rep rsync will do
        checksum for sharded files only</span></div>
    <div class="ace-line" id="magicdomid613"><span
        class="author-g-6mby7anhycxlsw8t">   - Geo-rep syncs each
        sharded files independently as new files</span></div>
    <div class="ace-line" id="magicdomid937"><span
        class="author-g-6mby7anhycxlsw8t">   - [UNKNOWN] Sync internal
        xattrs(file size and block count) in the main sharded file to
        Slave Volume to maintain the same state as in Master.</span></div>
    <div class="ace-line" id="magicdomid829"><span
        class="author-g-6mby7anhycxlsw8t">   - Sharding translator to
        allow file creation under .shards dir for gsyncd. that is Parent
        GFID is .shards directory<br>
      </span></div>
    <div class="ace-line" id="magicdomid938"><span
        class="author-g-6mby7anhycxlsw8t">   - If sharded files are
        modified during Geo-rep run may end up stale data in Slave.<br>
           - Files on Slave Volume may not be readable unless all
        sharded files sync to Slave(Each bricks in Master independently
        sync files to slave)<br>
      </span></div>
    <br>
    First approach looks more clean, but we have to analize the Rsync
    checksum performance on big files(Sharded in backend, accessed as
    one big file from rsync)<br>
    <br>
    Let us know your thoughts. Thanks<br>
    <br>
    Ref:<br>
    [1]
<a class="moz-txt-link-freetext" href="http://www.gluster.org/community/documentation/index.php/Features/sharding-xlator">http://www.gluster.org/community/documentation/index.php/Features/sharding-xlator</a><br>
    <pre class="moz-signature" cols="72">-- 
regards
Aravinda</pre>
  </body>
</html>