>>>>> "mj" == Moore, Joe <joe.mo...@siemens.com> writes:
mj> For a ZFS pool, (until block pointer rewrite capability) this
mj> would have to be a pool-create-time parameter.
naw. You can just make ZFS do it all the time, like the other storage
vendors do. no parameters.
You can invent parameter-free ways of turning it off. For example,
1. label the disk with an EFI label taking up the whole disk
2. point ZFS at slice zero instead of the whole disk, like
/dev/dsk/c0t0d0s0 instead of /dev/dsk/c0t0d0
3. ZFS will then be written to know it's supposed to use the entire
disk instead of writing a new label, but will still behave as
though it owns the disk cache-wise.
-or-
1. label the disk any way you like
2. point ZFS at the whole disk, /dev/dsk/c0t0d0. And make that
whole-disk device name work for all disks no matter what
controller, whether or not they're ``removeable,'' or how they're
labeled, like the equivalent device name does in Linux, FreeBSD,
and Mac OS X.
3. ZFS should remove your label and write a one-slice EFI label that
doesn't use the entire disk, and rounds down to a
bucketed/quantized/whole-ish number. If the disk is a replacement
for a component of an existing vdev, the EFI labelsize it picks
will be the *larger* of:
a. The right-size ZFS would have picked if the disk weren't a
replacement
b. the smallest existing component in the vdev
Most people will not even notice the feature exists except by getting
errors less often. AIUI this is how it works with other RAID layers,
the cheap and expensive alike among ``hardware'' RAID, and this
common-practice is very ZFS-ish. except hardware RAID is proprietary
so you cannot determine their exact policy, while in ZFS you would be
able to RTFS and figure it out.
But there is still no need for parameters. There isn't even a need to
explain the feature to the user.
I guess this has by now become a case of the silly unimportant but
easy-to-understand feature dominating the mailing list because it's so
obvious that everyone's qualified to pipe up with his opinion, so
maybe I'm a bit late and shuld have let it die.
pgpg3DEgtVtdm.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
