So it does look like something's messed up here. Before we pin this
down as a driver bug, we should double check that we are indeed opening
what we think we're opening, and try to track down why ldi_get_size is
failing. Try this:
#!/usr/sbin/dtrace -s
ldi_open_by_name:entry
{
trace(stringof(args[0]));
}
ldi_prop_exists:entry
{
trace(stringof(args[2]));
}
ldi_prop_exists:return
{
trace(arg1);
}
ldi_get_otyp:return
{
trace(arg1);
}
- Eric
On Wed, Jul 26, 2006 at 12:49:35PM -0600, David Curtis wrote:
> Eric,
>
> Here is what the customer gets trying to create the pool using the
> software alias: (I added all the ldi_open's to the script)
> # zpool create -f extdisk vpath1c
>
> # ./dtrace.script
> dtrace: script './dtrace.script' matched 6 probes
> CPU ID FUNCTION:NAME
> 0 7233 ldi_open_by_vp:return 0
> 0 15801 ldi_open_by_dev:return 0
> 0 7233 ldi_open_by_vp:return 0
> 0 15801 ldi_open_by_dev:return 0
> 0 7233 ldi_open_by_vp:return 0
> 0 15801 ldi_open_by_dev:return 0
> 0 7233 ldi_open_by_vp:return 0
> 0 15801 ldi_open_by_dev:return 0
> 0 7233 ldi_open_by_vp:return 0
> 0 15801 ldi_open_by_dev:return 0
> 0 7233 ldi_open_by_vp:return 0
> 0 15801 ldi_open_by_dev:return 0
> 0 7233 ldi_open_by_vp:return 0
> 0 15801 ldi_open_by_dev:return 0
> 0 7233 ldi_open_by_vp:return 0
> 0 15801 ldi_open_by_dev:return 0
> 0 7233 ldi_open_by_vp:return 0
> 0 17817 ldi_open_by_name:return 0
> 0 16191 ldi_get_size:return -1
> 0 44942 vdev_disk_open:return 22
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
