Not the whole raid set. It'll resilver what it needs to for the disk you are replacing.
But - yes... ultimately it'll resilver the whole pool by the time you have replaced all the disks.
One thing I'll add is that if your original disks are not 'advanced format' disks, and your new ones are, you really want to zfs send/receive lest you end up with 4K disks that ZFS treats as 512 byte block disks, and performance will absolutely reek.
My setup has 4 * Hitachi 4TB disks in it and using ashift of 12, they work just great.
When I tried them out with ashift of 9, they stunk. (As it happens, creating a brand new pool out of them defaulted to 4K. :) Good luck! On 12/12/2013 9:08 AM, Malcolm Herbert wrote:
On Wed, Dec 11, 2013 at 10:27:38PM +1100, Leigh Maddock wrote: |As far as I'm aware (someone please correct me if I'm wrong, it's been |awhile since I've played with this) you can't mirror at the vdev level, |so you have to replace disks at the individual disk level. On Thu, Dec 12, 2013 at 06:51:42AM +1100, Boyd Adamson wrote: |You can use zpool replace to replace each LUN one at a time. Thanks Leigh and Boyd - I'd seen references to this before but I was under the impression that doing this incurred a resilver of the entire raid set each time a LUN is replaced. Is this the case? I've made a start down the 'new pool + zfs send/receive' path as it also allows for fallback if required[1]. Regards, Malcolm [1] yes, I know, this wasn't listed as one of the constraints on the problem, sorry ... :) _______________________________________________ msosug mailing list [email protected] http://mexico.purplecow.org/m/listinfo/msosug
_______________________________________________ msosug mailing list [email protected] http://mexico.purplecow.org/m/listinfo/msosug
