<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Failed read recovery error in Disk</title>
    <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287140#M7069</link>
    <description>Fawrell,&lt;BR /&gt;&lt;BR /&gt;in most situations the continious surface scan that the raid controller firmware performes will detect inconsistencies and will correct them without the user knowing about them, however there can be situations whereby one disk faces a read error on the media and the other drive in the pair(assuming raid1 as an example here) has an issue in an area where the other copy of that record is stored, meaning that piece of data is lost since both are unreadable on both disks, this is a exceptional case.&lt;BR /&gt;This is not specific to the HP Smartarray but is something any raid controller in the industry can face.&lt;BR /&gt;&lt;BR /&gt;To answer your question on the backup of such situation ... well because the raid controller mirrors at the block level and is unaware of the user data itself, it might well be that the area with the unreadable data is not containing any user data at all.&lt;BR /&gt;If that is the case, your backup will be succesfull and there is no issue with the customers data and the problem is in unused space.&lt;BR /&gt;&lt;BR /&gt;It is thanks to the continious surface scan (some call it parity check i.e.) that such areas are detected before any customer data is written to them. When new data is written and that bad area is hit, the read afetr write verification will fail and the data will be written elsewhere.&lt;BR /&gt;&lt;BR /&gt;So when this bad spot on the disk media is detected and retries are not able to recover it, it is marked as 'bad' and not re-used anymore unless the array is initialized from scratch again after which those areas are ready to be used again which is not a problem because often this is a soft error (correctable via reformat)and not a hard media error on the platters of the disk.&lt;BR /&gt;When the disk reaches a certain number of errors (threshold set by the disk manufacturer, not by the raid controller) it will send out a pre-failure alert which will allow the customer to pro-actively replace the drive.&lt;BR /&gt;&lt;BR /&gt;The downside in such situations is that a rebuild will stick in the Ready for recovery status as you indicated or a Rebuild will start but stop and abort at some point when it hits the inconsistency and no valid/readable copy of a record is available to 100% succesfully rebuild the array.&lt;BR /&gt;&lt;BR /&gt;So bottom line is that if such a situation is what you hit, the full backup will tell you if the issue was within user data or not, if the backup fails with a read error i.e. then it is likely that you hit an issue with the inconsistency being in user data but this is more an exception due to all mechanism in place at the disk drive and raid controller level.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;HTH&lt;BR /&gt;&lt;BR /&gt;Kris</description>
    <pubDate>Thu, 16 Oct 2008 06:12:49 GMT</pubDate>
    <dc:creator>kris rombauts</dc:creator>
    <dc:date>2008-10-16T06:12:49Z</dc:date>
    <item>
      <title>Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287138#M7067</link>
      <description>Hi.&lt;BR /&gt;&lt;BR /&gt;   I have some questions about one SCSI S.M.A.R.T attribute Fl Rd Recv (in ADU 7.x). This should correspond to failed read recovery (unable to read the recovery info off of this drive). So this error should mean, that the drive was unable to read some data (hard read error) and it was unable to read recovery info for rebuild of this data. So the data are irretrievably lost. &lt;BR /&gt;&lt;BR /&gt;And my question is, when the drive has so serious error, why it is not marked in ADU as failed? When you have mirrored array and one disk in this array goes down and the second disk has failed read recovery errors, you cant rebuild the array. The array will stay in "Ready for recovery" state. And the only solution is to make backup, create new array with new drives and restore the backup there. But will I able to make backup from drive, that has some unreadable data on it?&lt;BR /&gt;&lt;BR /&gt;I think it is a serious error. But I can be worng in explaining of this error. So can someone tell me more about this error?&lt;BR /&gt;&lt;BR /&gt;Thanks for answers.</description>
      <pubDate>Wed, 15 Oct 2008 06:35:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287138#M7067</guid>
      <dc:creator>fawrell</dc:creator>
      <dc:date>2008-10-15T06:35:24Z</dc:date>
    </item>
    <item>
      <title>Re: Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287139#M7068</link>
      <description>Every RAID Unit will have its own parity layout thereby increasing reliability.&lt;BR /&gt;&lt;BR /&gt;The data Organization on a RAID volume is something like this:&lt;BR /&gt;&lt;BR /&gt;Where:&lt;BR /&gt;&lt;BR /&gt;Da,Db....Dz being data and Dp being parity&lt;BR /&gt;D1...Dn being the drives&lt;BR /&gt;&lt;BR /&gt;eg:On a RAID 5 volume here is how writes are done;&lt;BR /&gt;&lt;BR /&gt;D1   D2   D3     (Disks)&lt;BR /&gt;------------&lt;BR /&gt;Da | Db | Dp     (All Dp's are parities)&lt;BR /&gt;Dc | Dp | Dd&lt;BR /&gt;Dp | De | Df&lt;BR /&gt;------------&lt;BR /&gt;&lt;BR /&gt;Now the Fl Rd Recv error means, after a disk failure (Say D3), the controller should be able to re-create data from remaining data&lt;BR /&gt;which would be something like this;&lt;BR /&gt;&lt;BR /&gt;D1   D2     D3(replacement)     (Disks)&lt;BR /&gt;---------&lt;BR /&gt;Da | Db |   &amp;gt;&amp;gt;&amp;gt;&amp;gt; Dp&lt;BR /&gt;Dc | Dp |   &amp;gt;&amp;gt;&amp;gt;&amp;gt; Dd&lt;BR /&gt;Dp | De |   &amp;gt;&amp;gt;&amp;gt;&amp;gt; Df&lt;BR /&gt;&lt;BR /&gt;Now lets say we have an error in location Dc(on Disk 1)&lt;BR /&gt;which would be termed as Fl Rd Recv error.&lt;BR /&gt;&lt;BR /&gt;1) The rebuild will not complete&lt;BR /&gt;2) Backup may not complete some file(s) may &lt;BR /&gt;   be lost. (Filesystem Error correction will &lt;BR /&gt;   also mask these errors at times)&lt;BR /&gt;&lt;BR /&gt;Now since the drive firmware finds an error on the respective sector, it will re-direct  all the new writes to a new sector.&lt;BR /&gt;&lt;BR /&gt;However the drive may not have hit the threshold where it could be marked as failed, henceforth the message not showing up.Once the error count builds up then the drive will be failed or shows the predictive failure messages as applicable.&lt;BR /&gt;&lt;BR /&gt;As a best practice it is always good to have the drives replaced with new ones rather than  waiting for failure to show up;&lt;BR /&gt;&lt;BR /&gt;Hope this info was helpful;&lt;BR /&gt;&lt;BR /&gt;Cheers!&lt;BR /&gt;Shiva&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 15 Oct 2008 21:24:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287139#M7068</guid>
      <dc:creator>skris</dc:creator>
      <dc:date>2008-10-15T21:24:45Z</dc:date>
    </item>
    <item>
      <title>Re: Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287140#M7069</link>
      <description>Fawrell,&lt;BR /&gt;&lt;BR /&gt;in most situations the continious surface scan that the raid controller firmware performes will detect inconsistencies and will correct them without the user knowing about them, however there can be situations whereby one disk faces a read error on the media and the other drive in the pair(assuming raid1 as an example here) has an issue in an area where the other copy of that record is stored, meaning that piece of data is lost since both are unreadable on both disks, this is a exceptional case.&lt;BR /&gt;This is not specific to the HP Smartarray but is something any raid controller in the industry can face.&lt;BR /&gt;&lt;BR /&gt;To answer your question on the backup of such situation ... well because the raid controller mirrors at the block level and is unaware of the user data itself, it might well be that the area with the unreadable data is not containing any user data at all.&lt;BR /&gt;If that is the case, your backup will be succesfull and there is no issue with the customers data and the problem is in unused space.&lt;BR /&gt;&lt;BR /&gt;It is thanks to the continious surface scan (some call it parity check i.e.) that such areas are detected before any customer data is written to them. When new data is written and that bad area is hit, the read afetr write verification will fail and the data will be written elsewhere.&lt;BR /&gt;&lt;BR /&gt;So when this bad spot on the disk media is detected and retries are not able to recover it, it is marked as 'bad' and not re-used anymore unless the array is initialized from scratch again after which those areas are ready to be used again which is not a problem because often this is a soft error (correctable via reformat)and not a hard media error on the platters of the disk.&lt;BR /&gt;When the disk reaches a certain number of errors (threshold set by the disk manufacturer, not by the raid controller) it will send out a pre-failure alert which will allow the customer to pro-actively replace the drive.&lt;BR /&gt;&lt;BR /&gt;The downside in such situations is that a rebuild will stick in the Ready for recovery status as you indicated or a Rebuild will start but stop and abort at some point when it hits the inconsistency and no valid/readable copy of a record is available to 100% succesfully rebuild the array.&lt;BR /&gt;&lt;BR /&gt;So bottom line is that if such a situation is what you hit, the full backup will tell you if the issue was within user data or not, if the backup fails with a read error i.e. then it is likely that you hit an issue with the inconsistency being in user data but this is more an exception due to all mechanism in place at the disk drive and raid controller level.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;HTH&lt;BR /&gt;&lt;BR /&gt;Kris</description>
      <pubDate>Thu, 16 Oct 2008 06:12:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287140#M7069</guid>
      <dc:creator>kris rombauts</dc:creator>
      <dc:date>2008-10-16T06:12:49Z</dc:date>
    </item>
    <item>
      <title>Re: Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287141#M7070</link>
      <description>Thanks for your answers and time.&lt;BR /&gt;&lt;BR /&gt;Kris just one more question. &lt;BR /&gt;&lt;BR /&gt;"So when this bad spot on the disk media is detected and retries are not able to recover it, it is marked as 'bad' and not re-used anymore ..."&lt;BR /&gt;&lt;BR /&gt;I know when this error apears during rebuild, rebuild will not continue. But when this error appears before rebuild and the bad spot on the disk media will be marked as 'bad' and not re-used anymore, will the rebuild competed successfully?</description>
      <pubDate>Thu, 16 Oct 2008 13:12:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287141#M7070</guid>
      <dc:creator>fawrell</dc:creator>
      <dc:date>2008-10-16T13:12:52Z</dc:date>
    </item>
    <item>
      <title>Re: Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287142#M7071</link>
      <description>Not usually.&lt;BR /&gt;Backup&lt;BR /&gt;Replace the disks and restore, before you can not.</description>
      <pubDate>Thu, 16 Oct 2008 13:36:16 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287142#M7071</guid>
      <dc:creator>e4services</dc:creator>
      <dc:date>2008-10-16T13:36:16Z</dc:date>
    </item>
    <item>
      <title>Re: Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287143#M7072</link>
      <description>But when this error appears before rebuild and the bad spot on the disk media will be marked as 'bad' and not re-used anymore, will the rebuild competed successfully?&lt;BR /&gt;&lt;BR /&gt;Yes, because of the following reasons:&lt;BR /&gt;&lt;BR /&gt;1) A rebuild is triggered after a drive failure&lt;BR /&gt;2) So if a parity error is detected, the &lt;BR /&gt;   information is recreated from the bits and &lt;BR /&gt;   pieces available from the remaining drive &lt;BR /&gt;   and stored in a new location.&lt;BR /&gt;3) MSA does periodic scrubs which will &lt;BR /&gt;   simulate disk i/o and moves/recreates &lt;BR /&gt;   data if it finds a fault.&lt;BR /&gt;&lt;BR /&gt;Cheers!&lt;BR /&gt;Shiva&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 16 Oct 2008 20:34:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287143#M7072</guid>
      <dc:creator>skris</dc:creator>
      <dc:date>2008-10-16T20:34:54Z</dc:date>
    </item>
    <item>
      <title>Re: Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287144#M7073</link>
      <description>Or, No, as you stated, the rebuild fails due to MORE bad sectors.&lt;BR /&gt;Backup and restore to new drives as soon as possible</description>
      <pubDate>Fri, 17 Oct 2008 03:10:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287144#M7073</guid>
      <dc:creator>e4services</dc:creator>
      <dc:date>2008-10-17T03:10:57Z</dc:date>
    </item>
    <item>
      <title>Re: Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287145#M7074</link>
      <description>Thanks for answers again.&lt;BR /&gt;&lt;BR /&gt;One more question (hope last).&lt;BR /&gt;&lt;BR /&gt;When the error occurs on drive in RAID 1 array, but the array has only this one drive, will the rebuild after the insert of a new drive completed successfully?</description>
      <pubDate>Fri, 17 Oct 2008 09:15:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287145#M7074</guid>
      <dc:creator>fawrell</dc:creator>
      <dc:date>2008-10-17T09:15:52Z</dc:date>
    </item>
    <item>
      <title>Re: Failed read recovery error</title>
      <link>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287146#M7075</link>
      <description>it depends ...&lt;BR /&gt;&lt;BR /&gt;1)if the error is one that is correctable and a alternate (spare) location is used to store the data then no problem and it is transparent because this is handled at the hard disk level.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;2) if it is a hard error (unrecoverable) then the rebuild will fail because when the rebuild is copying onto the newly inserted disk and reaches the 'bad spot' on the source drive, the read fails and the rebuild will halt and you won't be able to get back to a redundant RAID1 and backup/re-init/restore will be needed to fix it.&lt;BR /&gt;&lt;BR /&gt;HTH&lt;BR /&gt;&lt;BR /&gt;Kris&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Oct 2008 09:54:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk/failed-read-recovery-error/m-p/4287146#M7075</guid>
      <dc:creator>kris rombauts</dc:creator>
      <dc:date>2008-10-17T09:54:34Z</dc:date>
    </item>
  </channel>
</rss>

