G'Day, On Sat, Mar 01, 2008 at 08:58:53PM -0800, Bill Shannon wrote: > Roch Bourbonnais wrote: > >>> this came up sometime last year .. io:::start won't work since ZFS > >>> doesn't call bdev_strategy() directly .. you'll want to use something > >>> more like zfs_read:entry, zfs_write:entry and zfs_putpage or zfs_getpage > >>> for mmap'd ZFS files > >> > > > > Ed: > > That's not entirely accurate. I believe ZFS does lead to bdev_strategy > > being called and io:::start > > will fire for ZFS I/Os. The problem is that a ZFS I/O can be servicing a > > number of ZFS operations on a > > number of different files (which is a great performance enabler). Given > > that we can't map an I/O to a file, > > iosnoop does not report the file info. > > Still seems like iosnoop ought to be fixed, or a warning added.
Yes, I've added that to my todo list. It should explain why in Notes/iosnoop_notes.txt, and note the behaviour of the cached pathname in the manpage and the script. Sorry for the confusion. I'll investigate if it's appropriate to include fssnoop/fstop scripts, for snooping at the VFS level (especially if I can make them fsinfo::: based) where pathnames should still be available in ZFS. It'll include logical I/O, but may still solve the question of which files and which processes are causing disk I/O. This is the correct forum for DTraceToolkit bugs, BTW. I might not be able to respond right away, but they will get read and added to the DTraceToolkit todo list if appropriate. :) cheers, Brendan -- Brendan [CA, USA] _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
