<?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: quote procedural question in Disk Enclosures</title>
    <link>https://community.hpe.com/t5/disk-enclosures/quote-procedural-question/m-p/2553114#M2295</link>
    <description>I don't like the sound of what you are proposing.  &lt;BR /&gt;&lt;BR /&gt;I don't have an FC60, so I can't say for sure, but if you lose a disk and the array gets rebuilt to the hot spare, then you replace the disk that went bad, doesn't that disk then become the hot spare?&lt;BR /&gt;&lt;BR /&gt;I see no reason to intentionally force the array to rebuild itself when it is not necessary.  You are unnecessarily causing more load, and slower access on the array.  At least from my perspective.</description>
    <pubDate>Mon, 16 Jul 2001 15:36:02 GMT</pubDate>
    <dc:creator>Patrick Wallek</dc:creator>
    <dc:date>2001-07-16T15:36:02Z</dc:date>
    <item>
      <title>quote procedural question</title>
      <link>https://community.hpe.com/t5/disk-enclosures/quote-procedural-question/m-p/2553113#M2294</link>
      <description>We have a FC60 with a global hot spare. Now if a disk goes bad it will automatically start rebuilding the disk to the hot spare. My question is once we get a new disk what is the best way to use that rather than the hot spare. I am thinking that you would do the following...  &lt;BR /&gt;&lt;BR /&gt;1) wait until the hot spare has been built and you have a replacment disk&lt;BR /&gt;2)pull out the hot spare&lt;BR /&gt;3) put in the replacement disk in the same position as before&lt;BR /&gt;4) tell the array to rebuid&lt;BR /&gt;5) put the hot spare back in and tell the system that it should be a hot spare. &lt;BR /&gt;&lt;BR /&gt;How does this sound? Is there a better way? Thanks in advance.&lt;BR /&gt;&lt;BR /&gt;Quin</description>
      <pubDate>Mon, 16 Jul 2001 13:43:13 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/quote-procedural-question/m-p/2553113#M2294</guid>
      <dc:creator>Quin Hammes</dc:creator>
      <dc:date>2001-07-16T13:43:13Z</dc:date>
    </item>
    <item>
      <title>Re: quote procedural question</title>
      <link>https://community.hpe.com/t5/disk-enclosures/quote-procedural-question/m-p/2553114#M2295</link>
      <description>I don't like the sound of what you are proposing.  &lt;BR /&gt;&lt;BR /&gt;I don't have an FC60, so I can't say for sure, but if you lose a disk and the array gets rebuilt to the hot spare, then you replace the disk that went bad, doesn't that disk then become the hot spare?&lt;BR /&gt;&lt;BR /&gt;I see no reason to intentionally force the array to rebuild itself when it is not necessary.  You are unnecessarily causing more load, and slower access on the array.  At least from my perspective.</description>
      <pubDate>Mon, 16 Jul 2001 15:36:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/quote-procedural-question/m-p/2553114#M2295</guid>
      <dc:creator>Patrick Wallek</dc:creator>
      <dc:date>2001-07-16T15:36:02Z</dc:date>
    </item>
    <item>
      <title>Re: quote procedural question</title>
      <link>https://community.hpe.com/t5/disk-enclosures/quote-procedural-question/m-p/2553115#M2296</link>
      <description>My bad here. I missed the line in the manual. once you replace a disk that went bad, the hotspare will go back to being a hot spare once the info has been transferred to the new disk. The reason that you don't want to use the hotspare forever is if the hotspare is on the same channel as another disk in the raid group. my having two disks on the same channel, you have a single point of failure for the raid group.</description>
      <pubDate>Mon, 16 Jul 2001 16:58:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/disk-enclosures/quote-procedural-question/m-p/2553115#M2296</guid>
      <dc:creator>Quin Hammes</dc:creator>
      <dc:date>2001-07-16T16:58:58Z</dc:date>
    </item>
  </channel>
</rss>

