<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:arial">On Fri, Feb 28, 2014 at 6:28 PM, Ravishankar N </span><span dir="ltr" style="font-family:arial"><<a href="mailto:ravishankar@redhat.com" target="_blank">ravishankar@redhat.com</a>></span><span style="font-family:arial"> wrote:</span></div>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="font-family:arial,helvetica,sans-serif">My
suggestion is to eliminate the zero-byte file from heal
source even if is marked as a source. If the underlying
filesystem finds some corruption (by scrubbing daemon
after checking data checksum), it could truncate it to 0
and let glusterfs to do the healing job.</div>
</div>
</div>
</div>
</blockquote></div>
If there is underlying FS corruption and we need to make gluster
aware of it, then something like bit rot detection would be the way
to go. You can find more information about some work in progress on
the gluster website/ mailing list archives:<br>
<a href="http://www.gluster.org/community/documentation/index.php/Arch/BitRot_Detection" target="_blank">http://www.gluster.org/community/documentation/index.php/Arch/BitRot_Detection</a><br>
<a href="http://lists.nongnu.org/archive/html/gluster-devel/2014-01/msg00209.html" target="_blank">http://lists.nongnu.org/archive/html/gluster-devel/2014-01/msg00209.html</a><br>
<a href="https://lists.gnu.org/archive/html/gluster-devel/2014-01/msg00006.html" target="_blank">https://lists.gnu.org/archive/html/gluster-devel/2014-01/msg00006.html</a><br>
<br>
-Ravi<div class=""><br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks for your material. I agree with the point from the discussion that glusterfs should make good use of checksum capability of the underlying filesystem (such as btrfs), for both simplicity and efficiency.</div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="font-family:arial,helvetica,sans-serif"> Here is
several cases of analysis in my mind.</div>
<div style="font-family:arial,helvetica,sans-serif">1. If this
corrupted file is marked as the only source, then there is
no correct replica in the filesystem (actually all are
fools), just pick any one as the source to heal is OK;</div>
<div style="font-family:arial,helvetica,sans-serif">2. If the
corrupted file is one of the potential sources, eliminate
this one should keep healing in the right direction
without further corrupting other correct replicas.</div>
<div style="font-family:arial,helvetica,sans-serif">3. If the
corrupted file is not marked as a source, some other
replica will be chosen as a source and this file will be
overwritten with correct data.</div>
<div style="font-family:arial,helvetica,sans-serif">4. If there
is no one is marked as clean by attribute, it is quite
unlikely this file is chosen as a source as its size is 0.
Even it is chosen as a source, there is no further
corruption of file content after heal.</div>
</div></div></div></blockquote></div></div></blockquote></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">On the other hand, I think this might be a fix/improvment for the current status, for both adding further check to the underlying corruption and a simple way of underlying filesystem to tell glusterfs it has corruption in some file.</div>
<br></div><div class="gmail_extra"><br clear="all"><div>Zhang Huan</div></div></div>