On Sun, Jan 18, 2009 at 8:25 PM, Richard Elling <richard.ell...@sun.com> wrote: > Peter Tribble wrote: >> See fsstat, which is based upon kstats. One of the thing I want to do with >> JKstat is correlate filesystem operations with underlying disk operations. >> The >> hard part is actually connecting a filesystem to the underlying drives. >> That's >> harder with zfs as the disk I/O is mapped to a pool which has multiple >> filesystems. > > If we draw a stack with application on top, devices on bottom > then fsstat shows the load into the file system from above. > iostat shows load into the devices from above. But because file > systems like to do things like caching, wrangling metadata, > prefetching, coalescing, deferring writes, and prewriting data (eg ZIL). > it is really hard to make a 1:1 correlation between an application's > I/O activity and disk I/O -- except for a rather small subset of > overall activity. This is one reason some databases like to deal > with raw devices. It is also why performance work for databases is > often done with raw devices -- fewer moving parts. The upshot is that > if you are looking for a 1:1 relationship, you will be sad. Rather, > it is better to look at overall efficiencies, which are fairly well > presented.
Indeed. Perhaps I didn't put that clearly enough. What I'm interested in is comparing what goes in at the top (fsstat) with what you see at the bottom (iostat) - it's the differences that are interesting. The hard part of the mapping is working out where a given file operation ought to be associated with a given set of devices. Simple pooled storage is one thing - multiple devices can be associated with a given filesystem. Then put multiple filesystems into a pool and you can N filesystems atop M devices and my head explodes. >> I would like to see the pool statistics exposed as kstats, though, which >> would >> make it easier to analyse them with existing tools. > > I recall some discussion about kstats in ZFS for performance a few years > ago, but IIRC the concensus seemed to be that ZFS was not going to get > overloaded with zillions of kstats. Yes, but zero is a bit, well, small. Just being able to do zpool iostat with kstats would be a big win. (And zfs does have a reasonable number of kstats, although I'm not absolutely sure what all of them mean and what their stability levels are.) > BTW, I really like Peter's work on JKstat -- well done! Thanks! -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
