<html><head></head><body>I can but here's the thing: this is a new volume with one client throwing data at it and no underlying drive, network or kernel issues. It concerns me that the fs could be compromised in less than 5 minutes!<br>
<br>
Sean<br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><br><div class="gmail_quote">Brian Candler <B.Candler@pobox.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">On Sun, Jun 17, 2012 at 08:17:30AM -0400, Sean Fulton wrote:<br />> It's a replicated volume, but only one client was writing one<br />> process to the cluster, so I don't understand how you could have a<br />> split brain.<br /><br />The write has to be made to two places at once. From what I know (which is<br />not much), with native client it's the client that's responsible; with NFS I<br />presume it's the gluster NFS server which does it.<br /><br />> The other issue is that while making a tar of the<br />> static files on the replicated volume, I kept getting errors from<br />> tar that the file changed as we read it. This was content I had<br />> copied *to* the cluster, and only one client node was acting on it<br />> at a time, so there is no chance anyone or anything was updating the<br />> files. And this error was coming up every 6 to 10 files.<br /><br />!
Hmm,
sounds to me like it could be another symptom of replicas being out of<br />sync.<br /><br />Your underlying filesystem does have user_xattr support I presume?<br /><br />What if you run something across both bricks which shows the size and/or<br />sha1sum of each file, and compare them? (Something mtree-like, or just find<br />| xargs sha1sum)<br /></pre></blockquote></div></body></html>