[Gluster-users] timestamps getting updated during self-heal after primary brick rebuild

[Whit Blauvelt]

A small question: We know that one or two members of the dev team read these
emails. One said just yesterday he's more likely to see emails than bug
reports. Now, sometimes the response to an email showing an obvious bug is
"File a bug report please." But for something like this - yes timestamps are
data so this is a serious bug - it would be a healthy thing if someone on
the dev team would make a point of both acknowledging that it's a bug, and
taking responsibility for being sure the bug report is filed and assigned to
the right people, whether or not the email writer has taken that step.

If the team's too small to follow through like this, is someone advocating
with Red Hat for more staff? They've made a large investment in Gluster,
which they might want to protect by fully staffing it. It's the fault of the
firm, not current project staff, if the current staffing is too thin.

Apologies if these reflections are out of place in a community discussion.
But it's in the community's interest that Red Hat succeeds and profits from
its Gluster purchase.

Best,
Whit

On Wed, Mar 06, 2013 at 03:28:39AM -0500, John Mark Walker wrote:
> Hi Todd,
> 
> A general note here: when someone posts a question and noone responds,
> it's generally because either no one has seen that particular behavior and
> they don't know how to respond, or they didn't understand what you were
> saying. In this case, I'd say it is the former.
> 
> ----- Original Message -----
> > something entirely different.  We see the same behavior.  After
> > rebuilding the
> > first brick in the 2-brick replicate cluster, all file timestamps get
> > updated
> > to the time self-heal copies the data back to that brick.
> > 
> > This is obviously a bug in 3.3.1.  We basically did what's described
> > here:
> > 
> >   http://gluster.org/community/documentation/index.php/Gluster_3.2:_Brick_Restoration_-_Replace_Crashed_Server
> > 
> > and timestamps get updated on all files.  Can someone acknowledge
> > that this
> > sounds like a bug?  Does anyone care?
> 
> Please file a bug and include the relevant information at 
>    https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS
> 
> - after searching for any similar bugs, of course.
> 
> > 
> > Being relatively new to glusterfs, it's painful to watch the mailing
> > list and
> > even the IRC channel and see many folks ask questions with nothing
> > but
> > silence.  I honestly wasn't sure if glusterfs was actively being
> > supported
> 
> ??? Our IRC channel is one of the most active in the open source world. I'm honestly not sure what mailing lists or IRC channels you've been watching. 
> 
> 
> > anymore.  Given the recent flurry of mail about lack of documentation
> > I see
> > that's not really true.  Unfortunately, given that what I'm seeing is
> > a form
> > of data corruption (yes, timestamps do matter), I'm surprised
> > nobody's
> > interested to help figure out what's going wrong.  Hopefully it's
> > something
> > about the way I've build out cluster (though it seems less and less
> > likely
> > given we are able to replicate the problem so easily).
> 
> I can understand your frustration. I would be, also. However, given that I haven't heard of this problem before, I don't know how you were able to reproduce it. The best I can offer is that we'll investigate your bug report.
> 
> Thanks,
> JM
> 
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users