Drew,
OK this is definitely better, and does what we talked about today, It
now enforces the client to ensure in_vdev and in_zpool are set.
looks good from my perspective.
cheers
Matt
On 04/18/11 06:44 PM, Drew Fisher wrote:
Matt,
I think the easiest way to handle this is to trap on both in_type and
the resultant vdev_list. If a zpool has a vdev, we go find all the
devices that match both the zpool name and the in_vdev label. For
disks where in_vdev is set, but in_zpool is *NOT* set, we'll return an
empty list for vdev_list. If we trap on both, we can rightfully raise
a RuntimeError and not trash somebody's system.
I've respun the webrev in-place and added a third test to handle this
case. Everything appears to function as needed.
Can you take a look when you get a chance?
-Drew
On 4/18/11 10:40 AM, Matt Keenan wrote:
Drew,
For for logmirror perfect, thanks
For for uniquely identify, will only work if the device has both
in_zpool and in_vdev set on the device.
According to target dtd it is not a hard requirement to have both
set, as long as the device can be uniquely identified as belonging to
a single pool/vdev then either or both can be specified.
Whilst this does get around cud_ai issue, only because before passing
control to TI we specifically ensure all devices have both in_zpool
and in_vdev set, however other clients may not enforce this. TI
really should check if a device is uniquely identifiable, and if not,
just throw and exception, rather than attempt to create in incorrect
zpool setup and thus potentially destroy user data.
cheers
Matt
On 04/18/11 05:12 PM, Drew Fisher wrote:
Good morning!
Could I please get a code review for the following two bugs?
7037399 <http://monaco.us.oracle.com/detail.jsf?cr=7037399> TI
should uniquely identify what pool a device belongs in
7037405 <http://monaco.us.oracle.com/detail.jsf?cr=7037405> TI fails
for "logmirror" vdev type
http://cr.opensolaris.org/~drewfish/cr_7037405/
Testing done was via the new unittests to confirm expected behavior.
Thanks!
-Drew
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
