2012-10-13 0:41, Ian Collins пишет:
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 each of the first two disks. As a
result, when installing the OS, I always partition 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?
Technically - you can layout the spare disks similarly and attach
the partitions or slices as spares for pools.
However, in servers I've seen there were predominantly different
layout designs:
1) Dedicated root disks/mirrors - small enough for rpool/swap
tasks, nowadays perhaps SSDs or CF cards - especially if care
was taken to use the rpool device mostly for reads and place
all writes like swap and logs onto other pools;
2) For smaller machines with 2 or 4 disks, a partition (slice)
is made for rpool sized about 10-20Gb, and the rest is for
data pool vdevs. In case of 4-disk machines, the rpool can be
a two-way mirror and the other couple of disks can host swap
and/or dump in an SVM or ZFS mirror for example. The data pool
components are identically sized and form a mirror, raid10 or
a raidz1; rarely a raidz2 - that is assumed to have better
resilience to loss of ANY two disks than a raid10 resilient
to loss of CORRECT two disks (from different mirrors).
3) For todays computers with all disks being big, I'd also
make a smallish rpool, a large data pool on separate disks,
and use the extra space on the disks with rpool for something
else - be it swap in SVM-mirrored partition, a scratch pool
for incoming data or tests, etc.
Not that any of this is necessarily a best practice, but that's
just the way I was taught to do it and am used to. Using pool
components of the same size does also make replacements simpler ;)
//Jim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
