<?xml version="1.0"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:res="http://blogreen.org/TR/Resources" xmlns:bgn="http://blogreen.org" bgn:template-name="rss" version="2.0"><channel><title>Comments on Updating a ZFS Mirror</title><link>http://romain.blogreen.org/blog/2012/01/updating-a-zfs-mirror/</link><description></description><link xmlns="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://romain.blogreen.org/blog/2012/01/updating-a-zfs-mirror/comments-rss.xml"/>
    <item><title>Comment by Freddie Cash</title><description><![CDATA[
	  <p xmlns="http://www.w3.org/1999/xhtml">Just a note: you don't need to use <tt>zpool replace</tt> on
	      mirror vdevs.  Instead, just <tt>zpool detach</tt> the degraded
	      disk from the vdev (thus turning it into a single disk vdev).
	      And <tt>zpool attach</tt> the new disk to the remaining disk
	      (thus turning it back into a mirror vdev).</p>

	  <p xmlns="http://www.w3.org/1999/xhtml"><tt>zpool replace</tt> is only needed for raidz vdevs.</p>
      ]]></description><link>http://romain.blogreen.org/blog/2012/01/updating-a-zfs-mirror/#comment-1</link><guid isPermaLink="true">http://romain.blogreen.org/blog/2012/01/updating-a-zfs-mirror/#comment-1</guid><pubDate>Wed, 04 Jan 2012 15:51:49 -0800</pubDate></item>
    <item><title>Comment by Romain Tartière</title><description><![CDATA[
	  <p xmlns="http://www.w3.org/1999/xhtml">You are right: there is no <em>need</em> to <tt>zpool replace</tt>
	      in this case.  In fact, the man page indicates that this command
	      does what you say in a single step (the only difference is the
	      order of operations, and it's not critical):</p>
	  <blockquote xmlns="http://www.w3.org/1999/xhtml" class="man">    <strong>zpool</strong> <strong>replace</strong> [<strong>-f</strong>] <em>pool</em> <em>old_device</em> [<em>new_device</em>]

        Replaces <em>old_device</em> with <em>new_device</em>. This is equivalent to  attach-
        ing  <em>new_device</em>,  waiting  for  it  to resilver, and then detaching
        <em>old_device</em>.</blockquote>
        <p xmlns="http://www.w3.org/1999/xhtml">Let's face it: I am a lazy sysadmin ;-)</p>
      ]]></description><link>http://romain.blogreen.org/blog/2012/01/updating-a-zfs-mirror/#comment-2</link><guid isPermaLink="true">http://romain.blogreen.org/blog/2012/01/updating-a-zfs-mirror/#comment-2</guid><pubDate>Thu, 05 Jan 2012 11:38:24 +0100</pubDate></item>
    <item><title>Comment by Firesock Serwalek</title><description><![CDATA[
	  <p xmlns="http://www.w3.org/1999/xhtml">There may actually be an advantage to doing the replace method
	      (and the order) over detach/attach. When you detach, certain
	      details are removed from the disk, so if something goes wrong
	      during the resilver, you can't just attempt to pop it back in.
	      Presumably this is the reason behind the ordering of operations
	      as well.</p>

	  <p xmlns="http://www.w3.org/1999/xhtml">More details here:<br/>
	      <a href="http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg15620.html">http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg15620.html</a></p>
      ]]></description><link>http://romain.blogreen.org/blog/2012/01/updating-a-zfs-mirror/#comment-3</link><guid isPermaLink="true">http://romain.blogreen.org/blog/2012/01/updating-a-zfs-mirror/#comment-3</guid><pubDate>Sun, 05 Aug 2012 20:06:40 +0100</pubDate></item>
    </channel></rss>