Please see comments/questions inline.<br><div class="gmail_quote"><span dir="ltr"></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm also noticing a problem with file times using AFR<br>
<br>
it seems that the file times get set to the time the file was AFR'ed<br>
to the other server.</blockquote><div><br>Do you mean "heal"ed to the other server? In normal operation AFR modifies both servers together at the same time.<br> </div><div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
here's what happens.<br>
we have a process which modifies a file at 1:17 on server1<br>
this file get's AFR'ed to server 2, but it takes some time and the<br>
file gets there at 1:18<br>
</blockquote><div><br>What do you mean 'a file is modified at 1:17 on server1' ? Is it modifying the backend directly? Is it modifying from the mountpoint with server2 offline? Or are you just considering a network delay pushing the 'modification' to happen a minute late on server2?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
so, the process which updated the file knows it was updated at 1:17,<br>
it now connects to the other server and sees that the file there is<br>
newer than it thinks it should be so it raises an error.<br>
</blockquote><div><br>As long as both the servers are online, the times are returned from the first subvolume, so in both the cases the process should see the mtime at 1:17.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Also, I believe this is part of the problem with what I'm currently<br>
getting, which are a bunch of Input/Output errors from gluster itself.<br>
the error logs look like this:<br>
[afr-self-heal-data.c:767:afr_sh_data_fix] home: Unable to resolve<br>
conflicting data of /XYZ/public_html/brokenfile. Please resolve<br>
manually by deleting the file /XYZ/public_html/brokenfile from all<br>
but the preferred subvolume<br>
[fuse-bridge.c:605:fuse_fd_cbk] glusterfs-fuse: 3013026: OPEN()<br>
/XYZ/public_html/brokenfile => -1 (Input/output error)<br>
<br>
the frustration is that in these cases both servers are on and active<br>
and working yet, gluster seems to be causing it's own<br>
problems. Again, I believe it's dues to the timestamps on the<br>
underlying filesystem not being what is expected.<br>
</blockquote><div><br>The EIO problem is unrelated to mtimes. We are investigating the EIO problem already.<br><br>avati<br></div></div><br>