Please see comments/questions inline. I'm also noticing a problem with file times using AFR > > it seems that the file times get set to the time the file was AFR'ed > to the other server. Do you mean "heal"ed to the other server? In normal operation AFR modifies both servers together at the same time. here's what happens. > we have a process which modifies a file at 1:17 on server1 > this file get's AFR'ed to server 2, but it takes some time and the > file gets there at 1:18 > 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? so, the process which updated the file knows it was updated at 1:17, > it now connects to the other server and sees that the file there is > newer than it thinks it should be so it raises an error. > 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. > > Also, I believe this is part of the problem with what I'm currently > getting, which are a bunch of Input/Output errors from gluster itself. > the error logs look like this: > [afr-self-heal-data.c:767:afr_sh_data_fix] home: Unable to resolve > conflicting data of /XYZ/public_html/brokenfile. Please resolve > manually by deleting the file /XYZ/public_html/brokenfile from all > but the preferred subvolume > [fuse-bridge.c:605:fuse_fd_cbk] glusterfs-fuse: 3013026: OPEN() > /XYZ/public_html/brokenfile => -1 (Input/output error) > > the frustration is that in these cases both servers are on and active > and working yet, gluster seems to be causing it's own > problems. Again, I believe it's dues to the timestamps on the > underlying filesystem not being what is expected. > The EIO problem is unrelated to mtimes. We are investigating the EIO problem already. avati -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zresearch.com/pipermail/gluster-users/attachments/20081124/830f6d1e/attachment.htm
