On 01/18/11 03:34 PM, Drew Fisher wrote:
Dave,
In general, I like this, as it does require less artificial naming of
objects. A couple of things.
1. The zpool attribute on the disk_name element would seemingly be
redundant if the vdev names were required to be unique across all
pools in the manifest. Undecided whether that's a good thing or not.
We could perhaps make the zpool attribute optional, only required if
the vdev names are not unique.
I don't think we should enforce the zpool name in the vdev label. I did
that for readability, but as you'll see below, it's not necessary. I
would be concerned that users wouldn't follow that naming convention and
it could cause all kinds of issues.
I wasn't suggesting that we enforce that a pool name is part of the vdev
attribute, just noting that the vdev name is likely sufficient in the
usual case. It's just the "leaf" of a "path", in other words, and if
the leaves are all uniquely named, you don't need the whole path and can
handle it like SMF handles service names or pkg handles package names.
Eliminating unnecessary verbosity seems helpful here.
2. I think we need one more case, such as concatenated raidz stripes.
A pretty large (and real) example is below. The ZFS Configuration
Guide on solarisinternals.com also has some interesting configurations
that are similar to this.
<snip> giant zpool status dump
See attached XML file for my take at this.
Looks like what I expected, complete with creative editorializing :-)
I'm not sure what the rules are on combinations of redundancy values
offhand, we'd need to check that out.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
