<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi,</div><div><br></div><div>i am trying to understand why georeplciation during &quot;History Crawl&quot; starts failing on each of the three bricks, one after the other. I have enabled DEBUG for all the logs configurable by the geo-replication command.</div><div><br></div><div>Running glusterfs v4.16 the behaviour is as follow:</div><div>- The &quot;History Crawl&quot; worked fine for about one hr, it actually replicated some files and folders albeit most of them looks empty</div><div>- at some point it starts becoming faulty, try to start on another brick, faulty and so on</div><div>- in the logs, Python exception above mentioned is raised:</div><div><span style="font-family:monospace,monospace">[2019-03-17 18:52:49.565040] E [syncdutils(worker /var/lib/heketi/mounts/vg_b088aec908c959c75674e01fb8598c21/brick_f90f425ecb89c3eec6ef2ef4a2f0a973/brick):332:log_raise_exception] &lt;top&gt;: FAIL:                                                                               <br>Traceback (most recent call last):<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/gsyncd.py&quot;, line 311, in main<br>    func(args)<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/subcmds.py&quot;, line 72, in subcmd_worker<br>    local.service_loop(remote)<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/resource.py&quot;, line 1291, in service_loop<br>    g3.crawlwrap(oneshot=True)<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/master.py&quot;, line 615, in crawlwrap<br>    self.crawl()<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/master.py&quot;, line 1569, in crawl<br>    self.changelogs_batch_process(changes)<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/master.py&quot;, line 1469, in changelogs_batch_process<br>    self.process(batch)<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/master.py&quot;, line 1304, in process<br>    self.process_change(change, done, retry)<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/master.py&quot;, line 1203, in process_change<br>    failures = self.slave.server.entry_ops(entries)<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/repce.py&quot;, line 216, in __call__<br>    return self.ins(self.meth, *a)<br>  File &quot;/usr/libexec/glusterfs/python/syncdaemon/repce.py&quot;, line 198, in __call__<br>    raise res<br>OSError: [Errno 1] Operation not permitted</span><br></div><div><br></div><div>- The operation before the exception:<br></div><div> <span style="font-family:monospace,monospace">[2019-03-17 18:52:49.545103] D [master(worker /var/lib/heketi/mounts/vg_b088aec908c959c75674e01fb8598c21/brick_f90f425ecb89c3eec6ef2ef4a2f0a973/brick):1186:process_change] _GMaster: entries: [{&#39;uid&#39;: 7575, &#39;gfid&#39;: &#39;e1ad7c98-f32a-4e48-9902-cc75840de7c3&#39;, &#39;gid&#39;: 100, &#39;mode&#39;<br>: 49536, &#39;entry&#39;: &#39;.gfid/5219e4b8-a1f3-4a4e-b9c7-c9b129abe671/.control_f7c33270dc9db9234d005406a13deb4375459715.6lvofzOuVnfAwOwY&#39;, &#39;op&#39;: &#39;MKNOD&#39;}, {&#39;gfid&#39;: &#39;e1ad7c98-f32a-4e48-9902-cc75840de7c3&#39;, &#39;entry&#39;: &#39;.gfid/5219e4b8-a1f3-4a4e-b9c7-c9b129abe671/.control_f7c33270dc9db9<br>234d005406a13deb4375459715&#39;, &#39;stat&#39;: {&#39;atime&#39;: 1552661403.3846507, &#39;gid&#39;: 100, &#39;mtime&#39;: 1552661403.3846507, &#39;uid&#39;: 7575, &#39;mode&#39;: 49536}, &#39;link&#39;: None, &#39;op&#39;: &#39;LINK&#39;}, {&#39;gfid&#39;: &#39;e1ad7c98-f32a-4e48-9902-cc75840de7c3&#39;, &#39;entry&#39;: &#39;.gfid/5219e4b8-a1f3-4a4e-b9c7-c9b129abe671/.con<br>trol_f7c33270dc9db9234d005406a13deb4375459715.6lvofzOuVnfAwOwY&#39;, &#39;op&#39;: &#39;UNLINK&#39;}]<br>[2019-03-17 18:52:49.548614] D [repce(worker /var/lib/heketi/mounts/vg_b088aec908c959c75674e01fb8598c21/brick_f90f425ecb89c3eec6ef2ef4a2f0a973/brick):179:push] RepceClient: call 56917:140179359156032:1552848769.55 entry_ops([{&#39;uid&#39;: 7575, &#39;gfid&#39;: &#39;e1ad7c98-f32a-4e48-9902-<br>cc75840de7c3&#39;, &#39;gid&#39;: 100, &#39;mode&#39;: 49536, &#39;entry&#39;: &#39;.gfid/5219e4b8-a1f3-4a4e-b9c7-c9b129abe671/.control_f7c33270dc9db9234d005406a13deb4375459715.6lvofzOuVnfAwOwY&#39;, &#39;op&#39;: &#39;MKNOD&#39;}, {&#39;gfid&#39;: &#39;<b>e1ad7c98-f32a-4e48-9902-cc75840de7c3</b>&#39;, &#39;entry&#39;: &#39;.gfid/5219e4b8-a1f3-4a4e-b9c7-c9b<br>129abe671/.control_f7c33270dc9db9234d005406a13deb4375459715&#39;, &#39;stat&#39;: {&#39;atime&#39;: 1552661403.3846507, &#39;gid&#39;: 100, &#39;mtime&#39;: 1552661403.3846507, &#39;uid&#39;: 7575, &#39;mode&#39;: 49536}, &#39;link&#39;: None, &#39;op&#39;: &#39;LINK&#39;}, {&#39;gfid&#39;: &#39;e1ad7c98-f32a-4e48-9902-cc75840de7c3&#39;, &#39;entry&#39;: &#39;.gfid/5219e4b8<br>-a1f3-4a4e-b9c7-c9b129abe671/<b>.control_f7c33270dc9db9234d005406a13deb4375459715.6lvofzOuVnfAwOwY&#39;, &#39;op&#39;</b>: &#39;UNLINK&#39;}],) ...</span><br></div><div><br></div><div>- The gfid highlighted, is pointing to these control files which are &quot;unix sockets&quot; as per below:<br></div><div><span style="font-family:monospace,monospace">rw-------  2 pippo users     0 Mar 14 16:32 .control_31c3a99664c1f956f949311e58434037e6a52d22<br>srw-------  2 pippo users     0 Mar 14 16:33 .control_a9b82937042529bca677b9f43eba9eb02ca7c5ee<br>srw-------  2 pippo users     0 Mar 14 16:32 .control_f429221460d52570066d9f25521011fe7e081cf5<br>srw-------  2 pippo users     0 Mar 15 15:50 .control_f7c33270dc9db9234d005406a13deb4375459715</span><br></div><div><br></div><div>So it seems geo-replicaiton should be at least skipping such file rather than raising an exception? Am i the first experiencing this behaviour?</div><div><br></div><div>thanks in advance</div><div>Davide<br></div></div></div></div></div></div>