Date: Mon, 30 Nov 2009 19:27:14 -0700 From: Josh Carter <josh@multipart-mixed.com> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: ZFS guidelines - preparing for future storage expansion Message-ID: <459EBAB9-483C-49B3-8B87-B3F3AEA3A03E@multipart-mixed.com> In-Reply-To: <5f67a8c40911301233s46a2818at9051c4ebbacf7e25@mail.gmail.com> References: <2ae8edf30911300120x627e42a9ha2cf003e847d4fbd@mail.gmail.com> <4B139AEB.8060900@jrv.org> <2ae8edf30911300425g4026909bm9262f6abcf82ddcd@mail.gmail.com> <5f67a8c40911301233s46a2818at9051c4ebbacf7e25@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 30, 2009, at 1:33 PM, Zaphod Beeblebrox wrote: > This form of upgrade is a cool feature --- in the end the "cost" of = running > a home RAID array is the cost of the electricity ... and I'm pretty = sure the > draw of the 1.5T drives is very similar to the 750G drives. I'm not = sure I > see this feature being used a lot in production, tho. It's a pretty = high > stress on the array for a long time. The best solution for production arrays hinges on this not-yet-done = feature, allowing the removal of a top-level vdev when there's = sufficient space on other vdevs: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D4852783 Assuming you've got several top-level vdevs, which is reasonable when = you've got a lot of drives, you'd want to migrate data off a vdev, pull = all the vdev's drives, and add new drives in their place. This both = saves hands-on time and there's no additional vulnerability to data = loss. FWIW, I asked the bug's owner about the status of this feature back in = April and he said "ETA into OpenSolaris this calendar year" but given = that the "commit to fix" field of the bug is still blank, I consider it = unlikely. One can still wish for a holiday gift. ;) -Josh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?459EBAB9-483C-49B3-8B87-B3F3AEA3A03E>