search for: bdev_strategy

I''m running OpenSolaris 2008.05 in VirtualBox on a Windows XP host. Playing around with various probes, I found that trying to load any probe associated with bdev_strategy dumps core. I can think of one or two likely and reasonable causes for this, but am assuming it''s undesirable behavior. Anyone know what''s happening here? -- This message posted from opensolaris.org

I''ve been looking into the performance impact of NCQ. Here''s what i found out: http://blogs.sun.com/erickustarz/entry/ncq_performance_analysis Curiously, there''s not too much performance data on NCQ available via a google search ... enjoy, eric

Hello, I can see that there is an implementation/emulation of ddi_pathname in DTrace, but I''m a bit confused about the capabilities and invocation of this function. I would like to diplay the path to the block device from bdev_strategy and other io:genunix::start probes. If someone is familiar with ddi_pathname, could you please provide an example invocation? Thanks, Michael This message posted from opensolaris.org

Hi, I''m working on some performance analysis with our database and it seems that when the file system (UFS) is mounted with forcedirectio, the IO probe are not triggered when an I/O event occurs. Could you confirm that ? If so, why ? Seb -- This message posted from opensolaris.org

...b930 sd:xbuf_iostart+103 () Oct 10 17:24:04 zetta genunix: [ID 655072 kern.notice] ffffff0007f1b960 sd:ddi_xbuf_qstrategy+60 () Oct 10 17:24:04 zetta genunix: [ID 655072 kern.notice] ffffff0007f1b9a0 sd:sdstrategy+ec () Oct 10 17:24:04 zetta genunix: [ID 655072 kern.notice] ffffff0007f1b9d0 genunix:bdev_strategy+77 () Oct 10 17:24:04 zetta genunix: [ID 655072 kern.notice] ffffff0007f1ba00 genunix:ldi_strategy+54 () Oct 10 17:24:04 zetta genunix: [ID 655072 kern.notice] ffffff0007f1ba50 zfs:vdev_disk_io_start+219 () Oct 10 17:24:04 zetta genunix: [ID 655072 kern.notice] ffffff0007f1ba70 zfs:vdev_io_start+1d...

Hi, I know how to trace the number of bytes read/written by a program by summing the argument of that read/write syscall. However, the way the OS services read/write calls is in blocks. I wonder if it''s possible to trace the actual number of blocks read/written caused by the syscalls? -- This message posted from opensolaris.org

...d:xbuf_iostart+103 () Sep 13 14:13:22 cypress genunix: [ID 655072 kern.notice] ffffff000840d1b0 sd:ddi_xbuf_qstrategy+60 () Sep 13 14:13:22 cypress genunix: [ID 655072 kern.notice] ffffff000840d1f0 sd:sdstrategy+ec () Sep 13 14:13:22 cypress genunix: [ID 655072 kern.notice] ffffff000840d220 genunix:bdev_strategy+77 () Sep 13 14:13:22 cypress genunix: [ID 655072 kern.notice] ffffff000840d250 genunix:ldi_strategy+54 () Sep 13 14:13:22 cypress genunix: [ID 655072 kern.notice] ffffff000840d2a0 zfs:vdev_disk_io_start+219 () Sep 13 14:13:22 cypress genunix: [ID 655072 kern.notice] ffffff000840d2c0 zfs:vdev_io_st...

Now at 36 hours since zdb process start and: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 827 root 4936M 4931M sleep 59 0 0:50:47 0.2% zdb/209 Idling at 0.2% processor for nearly the past 24 hours... feels very stuck. Thoughts on how to determine where and why? -- This message posted from opensolaris.org