<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>well ... not necessarily ðŸ˜„ <br>
but on the disk ... just as i expected ... taking it out helps a lot.<br>
<br>
Now on taking it out automatically when raising too many errors was a discussion i had several times with the GNR development.<br>
The issue really is .. I/O errors on disks (as seen in the mmlsrecoverygroupevent logs) can be due to several issues  (the disk itself,
<br>
the expander, the IOM, the adapter, the cable ... )<br>
in case of a more general part serving like 5 or more pdisks, that would risk the FT , if we took them out automatically. <br>
Thus ... we dont do that ..<br>
<br>
The idea is to improve the disk hospital more and more, so that the decision to switch a disk back to OK is more accurate,   over time. <br>
<br>
Until then .. it might always be a good idea to scan the event log for pdisk errors ... </div>
<div><br>
</div>
<div><span>
<pre>-- <br></pre>
<div data-evo-paragraph="" class="" style="width: 71ch;" data-evo-signature-plain-text-mode="">
Mit freundlichen Grüßen / Kind regards</div>
<div data-evo-paragraph="" class="" style="width: 71ch;"><br>
</div>
<div data-evo-paragraph="" class="" style="width: 71ch;">Achim Rehor</div>
<div data-evo-paragraph="" class="" style="width: 71ch;"><br>
</div>
<div data-evo-paragraph="" class="" style="width: 71ch;"><br>
</div>
</span></div>
<div><br>
</div>
<div>-----Original Message-----</div>
<div><b>From</b>: Jonathan Buzzard <<a href="mailto:Jonathan%20Buzzard%20%3cjonathan.buzzard@strath.ac.uk%3e">jonathan.buzzard@strath.ac.uk</a>></div>
<div><b>Reply-To</b>: gpfsug main discussion list <<a href="mailto:gpfsug%20main%20discussion%20list%20%3cgpfsug-discuss@gpfsug.org%3e">gpfsug-discuss@gpfsug.org</a>></div>
<div><b>To</b>: <a href="mailto:gpfsug-discuss@gpfsug.org">gpfsug-discuss@gpfsug.org</a></div>
<div><b>Subject</b>: [EXTERNAL] Re: [gpfsug-discuss] Bad disk but not failed in DSS-G</div>
<div><b>Date</b>: Mon, 24 Jun 2024 10:41:50 +0100</div>
<div><br>
</div>
<div>On 20/06/2024 23:32, Achim Rehor wrote:<br>
</div>
<div><br>
</div>
<div>[SNIP]<br>
</div>
<div><br>
</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div>Fred is most probably correct here. the two errors are not necessarily <br>
</div>
<div>the same.<br>
</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
<div>Turns out Fred was incorrect and having pushed the bad disk out the file <br>
</div>
<div>system the backups magically started working again. Not that, that <br>
</div>
<div>should come as the slightest surprise to anyone.<br>
</div>
<div><br>
</div>
<div>However finding I have a bad disk because the backups are failing is not <br>
</div>
<div>good at all because it means I can't rely on GPFS's health monitoring to <br>
</div>
<div>accurately report the state of the file system :-(<br>
</div>
<div><br>
</div>
<div>It also begs the question with hundreds of I/O errors on a disk why was <br>
</div>
<div>it not failed by GPFS? What criteria does GPFS use for deciding if a <br>
</div>
<div>disk is bad as clearly they are not accurate.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>JAB.<br>
</div>
<div><br>
</div>
</body>
</html>