<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Home Fileserver: RAIDZ expansion</title>
	<atom:link href="http://breden.org.uk/2008/09/01/home-fileserver-raidz-expansion/feed/" rel="self" type="application/rss+xml" />
	<link>http://breden.org.uk/2008/09/01/home-fileserver-raidz-expansion/</link>
	<description>May the force be with you!</description>
	<pubDate>Tue, 06 Jan 2009 02:51:43 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: kebabbert</title>
		<link>http://breden.org.uk/2008/09/01/home-fileserver-raidz-expansion/#comment-2611</link>
		<dc:creator>kebabbert</dc:creator>
		<pubDate>Fri, 26 Sep 2008 08:23:34 +0000</pubDate>
		<guid isPermaLink="false">http://breden.org.uk/?p=122#comment-2611</guid>
		<description>ERIC,

You can not easily expand an existing vdev as of now, but you can create a new vdev and add it to the ZFS raid.

Say you have 3 drives in a ZFS raid. Then you can add 3 more drives to that raid. So now you got a ZFS raid with 3 drives + 3 drives. On each set, one disc will be used for parity, so here you have 4 drives for storing data, and 2 drives for parity. All data will be shared on the ZFS raid, spread out evenly on the discs.

Alternatively, you could have created one ZFS raid with 6 drives. Then one of the drives would have been for parity and store data on 5 drives. This is the approach used in this article.

(When using many drives, 10 or more, the prefered approach is to have several smaller sets combined into one large ZFS raid. This is prefered on the SUN thumper machine which has 48 drives. Many smaller sets combined into one big ZFS raid is recommended. Just buy several SATA I/O cards with 8 connections, and you can have a thumper at home. Remember, ZFS prefers no hardware raid card. ZFS likes to have control of everything by itself. No hardware raid cards then).




Of course, you could add only one drive to your first set of 3 drives. Then you would have a ZFS raid with 3 drives + 1 drive. This would be bad, because what happens if that 1 drive fails? In the set of 3 drives, one drive can fail because that set has redundancy. But the second set has no redundancy. Therefore, add a group of drives to an existing ZFS raid. Within a group, the drives should have equal storing capacity.</description>
		<content:encoded><![CDATA[<p>ERIC,</p>
<p>You can not easily expand an existing vdev as of now, but you can create a new vdev and add it to the ZFS raid.</p>
<p>Say you have 3 drives in a ZFS raid. Then you can add 3 more drives to that raid. So now you got a ZFS raid with 3 drives + 3 drives. On each set, one disc will be used for parity, so here you have 4 drives for storing data, and 2 drives for parity. All data will be shared on the ZFS raid, spread out evenly on the discs.</p>
<p>Alternatively, you could have created one ZFS raid with 6 drives. Then one of the drives would have been for parity and store data on 5 drives. This is the approach used in this article.</p>
<p>(When using many drives, 10 or more, the prefered approach is to have several smaller sets combined into one large ZFS raid. This is prefered on the SUN thumper machine which has 48 drives. Many smaller sets combined into one big ZFS raid is recommended. Just buy several SATA I/O cards with 8 connections, and you can have a thumper at home. Remember, ZFS prefers no hardware raid card. ZFS likes to have control of everything by itself. No hardware raid cards then).</p>
<p>Of course, you could add only one drive to your first set of 3 drives. Then you would have a ZFS raid with 3 drives + 1 drive. This would be bad, because what happens if that 1 drive fails? In the set of 3 drives, one drive can fail because that set has redundancy. But the second set has no redundancy. Therefore, add a group of drives to an existing ZFS raid. Within a group, the drives should have equal storing capacity.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://breden.org.uk/2008/09/01/home-fileserver-raidz-expansion/#comment-2476</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Thu, 18 Sep 2008 20:41:42 +0000</pubDate>
		<guid isPermaLink="false">http://breden.org.uk/?p=122#comment-2476</guid>
		<description>Thanks Eric.

As you say, not being able to expand a RAIDZ vdev needn't be a problem if you are happy with simply adding an additional RAIDZ vdev when expanding your pool. I wanted to add just &lt;strong&gt;one drive&lt;/strong&gt; though, so adding a new vdev wasn't an option. The backup storage was no problem as I had sufficient spare capacity available.

I have noted my comments on Drobo here: http://breden.org.uk/2008/03/02/home-fileserver-existing-products/

The points I mentioned about Drobo were:

&lt;blockquote&gt;Drobo initially looked quite interesting, especially in its flexibility for handling different sized drives. However, it seems to suffer from pitifully slow transfer speeds due to using a USB2 interface, and its data format seems undocumented and, therefore, proprietary. I didn’t need to look any further. Also the price was around $500 without drives, so it’s not cheap either. I believe there is some kind of bolt-on box called DroboShare for giving ethernet access too, available for another $200. So this gizmo with ethernet access will cost $700 without any drives. No thanks.&lt;/blockquote&gt;

Yes, I think there will be a solution available for expanding RAIDZ vdevs sometime. The last time I looked, there was some info on how this might work here: http://blogs.sun.com/ahl/entry/expand_o_matic_raid_z</description>
		<content:encoded><![CDATA[<p>Thanks Eric.</p>
<p>As you say, not being able to expand a RAIDZ vdev needn&#8217;t be a problem if you are happy with simply adding an additional RAIDZ vdev when expanding your pool. I wanted to add just <strong>one drive</strong> though, so adding a new vdev wasn&#8217;t an option. The backup storage was no problem as I had sufficient spare capacity available.</p>
<p>I have noted my comments on Drobo here: <a href="http://breden.org.uk/2008/03/02/home-fileserver-existing-products/" rel="nofollow">http://breden.org.uk/2008/03/02/home-fileserver-existing-products/</a></p>
<p>The points I mentioned about Drobo were:</p>
<blockquote><p>Drobo initially looked quite interesting, especially in its flexibility for handling different sized drives. However, it seems to suffer from pitifully slow transfer speeds due to using a USB2 interface, and its data format seems undocumented and, therefore, proprietary. I didn’t need to look any further. Also the price was around $500 without drives, so it’s not cheap either. I believe there is some kind of bolt-on box called DroboShare for giving ethernet access too, available for another $200. So this gizmo with ethernet access will cost $700 without any drives. No thanks.</p></blockquote>
<p>Yes, I think there will be a solution available for expanding RAIDZ vdevs sometime. The last time I looked, there was some info on how this might work here: <a href="http://blogs.sun.com/ahl/entry/expand_o_matic_raid_z" rel="nofollow">http://blogs.sun.com/ahl/entry/expand_o_matic_raid_z</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric</title>
		<link>http://breden.org.uk/2008/09/01/home-fileserver-raidz-expansion/#comment-2463</link>
		<dc:creator>Eric</dc:creator>
		<pubDate>Thu, 18 Sep 2008 05:19:38 +0000</pubDate>
		<guid isPermaLink="false">http://breden.org.uk/?p=122#comment-2463</guid>
		<description>I have really enjoyed reading this series of posts, as I am in the planning stages of my home file server.

Unfortunately, I just can't justify jumping into ZFS when you cannot expand a raidz vdev. I know drobo and symilar units are expensive and proprietary. But the functionality of being able to expand an array by adding additional disks is just too valuable to me, and I would think it is similar for most other home users.

Call me strange, but I don't see much point in growing a raidz pool if you need enough temporary storage to store all of your data for backup anyway. At that point you could just use those drives to form a second raidz vdev and add it to your existing pool.

Is there any hope that ZFS will add this functionality? Don't worry, I'm not holding my breath.</description>
		<content:encoded><![CDATA[<p>I have really enjoyed reading this series of posts, as I am in the planning stages of my home file server.</p>
<p>Unfortunately, I just can&#8217;t justify jumping into ZFS when you cannot expand a raidz vdev. I know drobo and symilar units are expensive and proprietary. But the functionality of being able to expand an array by adding additional disks is just too valuable to me, and I would think it is similar for most other home users.</p>
<p>Call me strange, but I don&#8217;t see much point in growing a raidz pool if you need enough temporary storage to store all of your data for backup anyway. At that point you could just use those drives to form a second raidz vdev and add it to your existing pool.</p>
<p>Is there any hope that ZFS will add this functionality? Don&#8217;t worry, I&#8217;m not holding my breath.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://breden.org.uk/2008/09/01/home-fileserver-raidz-expansion/#comment-2371</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Tue, 02 Sep 2008 19:27:50 +0000</pubDate>
		<guid isPermaLink="false">http://breden.org.uk/?p=122#comment-2371</guid>
		<description>Hi Constantin, thanks a lot for the compliments and glad you like the writing style!

In the linked-to &lt;a href="http://breden.org.uk/2008/03/12/home-fileserver-backups/" rel="nofollow"&gt;backups article&lt;/a&gt;, I used rsync simply because I was not familiar at that time with zfs send / receive. Later, I wrote about using zfs send / receive for performing backups in this article: &lt;a href="http://breden.org.uk/2008/05/12/home-fileserver-backups-from-zfs-snapshots/" rel="nofollow"&gt;Home Fileserver: Backups from ZFS snapshots&lt;/a&gt;.

Thanks for writing all the great posts about ZFS on your blog, and I look forward to reading more in future. It was &lt;a href="http://blogs.sun.com/constantin/" rel="nofollow"&gt;your blog&lt;/a&gt; and &lt;a href="http://blogs.sun.com/timf/" rel="nofollow"&gt;Tim Foster's blog&lt;/a&gt; that inspired me when I first started looking into ZFS, so thanks again!

Cheers,
Simon</description>
		<content:encoded><![CDATA[<p>Hi Constantin, thanks a lot for the compliments and glad you like the writing style!</p>
<p>In the linked-to <a href="http://breden.org.uk/2008/03/12/home-fileserver-backups/" rel="nofollow">backups article</a>, I used rsync simply because I was not familiar at that time with zfs send / receive. Later, I wrote about using zfs send / receive for performing backups in this article: <a href="http://breden.org.uk/2008/05/12/home-fileserver-backups-from-zfs-snapshots/" rel="nofollow">Home Fileserver: Backups from ZFS snapshots</a>.</p>
<p>Thanks for writing all the great posts about ZFS on your blog, and I look forward to reading more in future. It was <a href="http://blogs.sun.com/constantin/" rel="nofollow">your blog</a> and <a href="http://blogs.sun.com/timf/" rel="nofollow">Tim Foster&#8217;s blog</a> that inspired me when I first started looking into ZFS, so thanks again!</p>
<p>Cheers,<br />
Simon</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Constantin Gonzalez</title>
		<link>http://breden.org.uk/2008/09/01/home-fileserver-raidz-expansion/#comment-2367</link>
		<dc:creator>Constantin Gonzalez</dc:creator>
		<pubDate>Tue, 02 Sep 2008 07:00:28 +0000</pubDate>
		<guid isPermaLink="false">http://breden.org.uk/?p=122#comment-2367</guid>
		<description>Hi Simon,

great blog entry, as always! I like the mix between casual style and solidly founded tech content.
Is there any particular reason why you prefer rsync over zfs send/receive for performing the backups?

Cheers,
   Constantin</description>
		<content:encoded><![CDATA[<p>Hi Simon,</p>
<p>great blog entry, as always! I like the mix between casual style and solidly founded tech content.<br />
Is there any particular reason why you prefer rsync over zfs send/receive for performing the backups?</p>
<p>Cheers,<br />
   Constantin</p>
]]></content:encoded>
	</item>
</channel>
</rss>
