> From: Ian Collins [mailto:i...@ianshome.com]
> On 10/13/12 02:12, Edward Ned Harvey
> (opensolarisisdeadlongliveopensolaris) wrote:
> > There are at least a couple of solid reasons *in favor* of partitioning.
> > #1 It seems common, at least to me, that I'll build a server with let's
> > say, 12
> disk slots, and we'll be using 2T disks or something like that. The OS itself
> only takes like 30G which means if I don't partition, I'm wasting 1.99T on
> of the first two disks. As a result, when installing the OS, I always
> rpool down to ~80G or 100G, and I will always add the second partitions of
> the first disks to the main data pool.
> How do you provision a spare in that situation?
A solid point. I don't.
This doesn't mean you can't - it just means I don't.
If I'm not mistaken... If you have a pool with multiple different sizes of
devices in the pool, you only need to add a spare of the larger size. If you
have a smaller device failure, I believe the pool will use the larger spare
device rather than not using a spare. So if I'm not mistaken, you can add a
spare to your pool exactly the same, regardless of having partitions or no
If I'm wrong - if the pool won't use the larger spare device in place of a
smaller failed device (partition), then you would likely need to add one spare
for each different size device used in your pool. In particular, this means:
Option 1: Given that you partition your first 2 disks, 80G for OS and 1.99T
for data, you would likely want to partition *all* your disks the same,
including the disk that's designated as a spare. Then you could add your spare
80G partition as a spare device, and your spare 1.99T partition as a spare
Option 2: Suppose you partition your first disks, and you don't want to hassle
on all the rest. (This is my case.) Or you have physically different size
devices, a pool that was originall made of 1T disks but now it's been extended
to include a bunch of 2T disks, or something like that. It's conceivable you
would want to have a spare of each different size, which could in some cases
mean you use two spares (one partitioned and one not) in a pool where you might
otherwise have only one spare.
zfs-discuss mailing list