<div dir="ltr">Hi Uwe,<div><br></div><div>You're right.. how would it know which one is the good one? I had imagined it would at least compare some piece of metadata to the block's metadata on retrieval, maybe generation number, something... However, when I think about that, it doesnt make any sense. The block on-disk is purely the data, no metadata. Thus, there won't be any structural issues when retrieving a bad block.</div><div><br></div><div>What is the tool in 4.2 that you are referring to for comparing replicas? I'd be interested in trying it out. I didn't happen to pass-by any mmrestripefs options for that.. maybe I missed something.</div><div>E2E I guess is what I'm looking for, but not on GNR. I'm just trying to investigate failure cases possible on standard-RAID hardware. I'm sure we've all had a RAID controller or two that have failed in interesting ways...</div><div><br></div><div>-Zach</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 5:22 AM, Uwe Falke <span dir="ltr"><<a href="mailto:UWEFALKE@de.ibm.com" target="_blank">UWEFALKE@de.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Zach,<br>
GPFS replication does not include automatically a comparison of the<br>
replica copies.<br>
It protects against one part (i.e. one FG, or two with 3-fold replication)<br>
of the storage being down.<br>
How should GPFS know what version is the good one if both replica copies<br>
are readable?<br>
<br>
There are tools in 4.x to compare the replicas, but do use them only from<br>
4.2 onward (problems with prior versions). Still then you need to decide<br>
what is the "good" copy (there is a consistency check on MD replicas<br>
though, but correct/incorrect data blocks cannot be auto-detected for<br>
obvious reasons). E2E Check-summing (as in GNR) would of course help here.<br>
<br>
<br>
Mit freundlichen Grüßen / Kind regards<br>
<br>
<br>
Dr. Uwe Falke<br>
<br>
IT Specialist<br>
High Performance Computing Services / Integrated Technology Services /<br>
Data Center Services<br>
-------------------------------------------------------------------------------------------------------------------------------------------<br>
IBM Deutschland<br>
Rathausstr. 7<br>
09111 Chemnitz<br>
Phone: <a href="tel:%2B49%20371%206978%202165" value="+4937169782165">+49 371 6978 2165</a><br>
Mobile: <a href="tel:%2B49%20175%20575%202877" value="+491755752877">+49 175 575 2877</a><br>
E-Mail: <a href="mailto:uwefalke@de.ibm.com">uwefalke@de.ibm.com</a><br>
-------------------------------------------------------------------------------------------------------------------------------------------<br>
IBM Deutschland Business & Technology Services GmbH / Geschäftsführung:<br>
Frank Hammer, Thorsten Moehring<br>
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart,<br>
HRB 17122<br>
<br>
<br>
<br>
<br>
From: Zachary Giles <<a href="mailto:zgiles@gmail.com">zgiles@gmail.com</a>><br>
To: gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org">gpfsug-discuss@spectrumscale.org</a>><br>
Date: 04/29/2016 06:22 AM<br>
Subject: [gpfsug-discuss] GPFS and replication.. not a mirror?<br>
Sent by: <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a><br>
<div><div class="h5"><br>
<br>
<br>
Fellow GPFS Users,<br>
<br>
I have a silly question about file replicas... I've been playing around<br>
with copies=2 (or 3) and hoping that this would protect against data<br>
corruption on poor-quality RAID controllers.. but it seems that if I<br>
purposefully corrupt blocks on a LUN used by GPFS, the "replica" doesn't<br>
take over, rather GPFS just returns corrupt data. This includes if just<br>
"dd" into the disk, or if I break the RAID controller somehow by yanking<br>
whole chassis and the controller responds poorly for a few seconds.<br>
<br>
Originally my thinking was that replicas were for mirroring and GPFS would<br>
somehow return whichever is the "good" copy of your data, but now I'm<br>
thinking it's just intended for better file placement.. such as having a<br>
near replica and a far replica so you dont have to cross buildings for<br>
access, etc. That, and / or, disk outages where the outage is not<br>
corruption, just simply outage either by failure or for disk-moves, SAN<br>
rewiring, etc. In those cases you wouldn't have to "move" all the data<br>
since you already have a second copy. I can see how that would makes<br>
sense..<br>
<br>
Somehow I guess I always knew this.. but it seems many people say they<br>
will just turn on copies=2 and be "safe".. but it's not the case..<br>
<br>
Which way is the intended?<br>
Has anyone else had experience with this realization?<br>
<br>
Thanks,<br>
-Zach<br>
<br>
<br>
--<br>
Zach Giles<br>
</div></div>zgiles@gmail.com_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Zach Giles<br><a href="mailto:zgiles@gmail.com" target="_blank">zgiles@gmail.com</a></div>
</div></div></div>