zfs discuss - May 2007 - Re: ZFS over a layered driver interface

With what Edward suggested, I got rid of the ldi_get_size() error by defining
the prop_op entry point appropriately.

However, the zpool create still fails - with zio_wait() returning 22.

bash-3.00# dtrace -n ''fbt::ldi_get_size:entry{self->t=1;}
fbt::ldi_get_size:entry/self->t/{}
fbt::ldi_get_size:return/self->t/{trace((int)arg1);}
fbt::ldi_get_size:return{self->t=0;}'' -c ''zpool create
adsl-pool /dev/layerzfsminor1''
dtrace: description ''fbt::ldi_get_size:entry'' matched 4 probes
cannot create ''adsl-pool'': invalid argument for this pool
operation
dtrace: pid 2487 has exited
CPU ID FUNCTION:NAME
0 21606 ldi_get_size:entry
0 21607 ldi_get_size:return 0

bash-3.00# dtrace -n ''fbt:zfs:zfs_ioc_pool_create:entry{self->t=1;}
fbt:zfs::return/self->t && arg1 == 22/{stack(); exit(0);}
fbt:zfs:zfs_ioc_pool_create:return{self->t=0;}''
dtrace: description ''fbt:zfs:zfs_ioc_pool_create:entry''
matched 1317 probes
CPU ID FUNCTION:NAME
0 63848 zio_wait:return
zfs`vdev_label_init+0x4ed
zfs`vdev_label_init+0x4e
zfs`vdev_create+0x4b
zfs`spa_create+0x233
zfs`zfs_ioc_pool_create+0x4a
zfs`zfsdev_ioctl+0x119
genunix`cdev_ioctl+0x48
specfs`spec_ioctl+0x86
genunix`fop_ioctl+0x37
genunix`ioctl+0x16b
unix`sys_syscall32+0x101


I see the strategy routine of my layered driver being invoked, and reads and
writes are being done. (in the more detailed dtrace dump, I see
zio_vdev_io_start and other zio functions being invoked).
Is there a way to figure out where exactly this is breaking?
Could it be due to an ioctl failure, since the kernel log shows a failure for
the ioctl to the real device?

Thanks,
Swetha.
 
 
This message posted from opensolaris.org

hey swetha,
i don''t think there is any easy answer for you here.

i''d recommend watching all device operations (open, read, write, ioctl,
strategy, prop_op, etc) that happen to the ramdisk device when you
don''t
use your layered driver, and then again when you do.  then you could
compare the two to see what the differences are.  or optionally, you
could do some more analysis into that ioctl failure to see if it''s
an important ioctl that should be succeeding and instead is causing
a cascading failure.  to investigate both of these possiblilties i''d
recommend using dtrace fbt probes, the answer won''t be easy to find,
but dtrace will make finding it easier.

lastly, you could start analyzing to see what zio_wait() is waiting for.
for this you''d want to use mdb -k to look at the current kernel state
and compare that to the source to see what zfs is trying to do and what
it''s blocked on.  (you might actually consider forcing a crash dump
and analyzing it offline, since then the state is not changing and you
can always come back to it.)

ed


On Tue, May 15, 2007 at 01:12:06PM -0700, Shweta Krishnan
wrote:
> With what Edward suggested, I got rid of the ldi_get_size() error by
defining the prop_op entry point appropriately.
>
> However, the zpool create still fails - with zio_wait() returning 22.
>
> bash-3.00# dtrace -n ''fbt::ldi_get_size:entry{self->t=1;}
fbt::ldi_get_size:entry/self->t/{}
fbt::ldi_get_size:return/self->t/{trace((int)arg1);}
fbt::ldi_get_size:return{self->t=0;}'' -c ''zpool create
adsl-pool /dev/layerzfsminor1''
> dtrace: description ''fbt::ldi_get_size:entry'' matched 4
probes
> cannot create ''adsl-pool'': invalid argument for this pool
operation
> dtrace: pid 2487 has exited
> CPU ID FUNCTION:NAME
> 0 21606 ldi_get_size:entry
> 0 21607 ldi_get_size:return 0
>
> bash-3.00# dtrace -n
''fbt:zfs:zfs_ioc_pool_create:entry{self->t=1;}
fbt:zfs::return/self->t && arg1 == 22/{stack(); exit(0);}
fbt:zfs:zfs_ioc_pool_create:return{self->t=0;}''
> dtrace: description ''fbt:zfs:zfs_ioc_pool_create:entry''
matched 1317 probes
> CPU ID FUNCTION:NAME
> 0 63848 zio_wait:return
> zfs`vdev_label_init+0x4ed
> zfs`vdev_label_init+0x4e
> zfs`vdev_create+0x4b
> zfs`spa_create+0x233
> zfs`zfs_ioc_pool_create+0x4a
> zfs`zfsdev_ioctl+0x119
> genunix`cdev_ioctl+0x48
> specfs`spec_ioctl+0x86
> genunix`fop_ioctl+0x37
> genunix`ioctl+0x16b
> unix`sys_syscall32+0x101
>
>
> I see the strategy routine of my layered driver being invoked, and reads
and writes are being done. (in the more detailed dtrace dump, I see
zio_vdev_io_start and other zio functions being invoked).
> Is there a way to figure out where exactly this is breaking?
> Could it be due to an ioctl failure, since the kernel log shows a failure
for the ioctl to the real device?
>
> Thanks,
> Swetha.
>
>
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss