kstat support

[Emmanuel Anne]

Ok, it's committed.
So it adds a new /zfs-kstat directory full of zfs attributes, a little like the /proc directory.
For now all the attributes are read-only, but can be accessed by anyone.
Pass --no-kstat-mount argument to zfs-fuse if you don't want to see this directory.
The directory is created when needed and destroyed when the zfs-fuse daemon exits.

I also included a new arcstat.pl script in the contrib directory which is a modified version of this same script available somewhere on the web to work with the /zfs-kstat directory instead of the SUN:: Solaris::Kstat module.

And finally you'll also find a unix directory inside with some kstats about tasks, but even if zfs-fuse creates them, they are not updated (it's new for me too !).
So the only interesting part is in /zfs-kstat/zfs
I guess tuning some parameters from this data will take quite some time. A 1st surprise is already the amount of hits in ARC. Normally the kernel cache should cache most of the data, and ARC should get almost nothing, and it's clearly not the case for now...

--
zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary

[jafo]

Nicely done, thanks. I'll try to play around with it soon. I need to
decide if I need to set up another test machine, or what; I don't want
to
stop the current tests I'm running.

Sean

[Emmanuel Anne]

Anyway there are probably still some data missing from the kstats because the size of arc is mostly constant over time.
So the increase in memory usage is not from arc.
There are 2 other caches listed, but no size info from them, so I guess we'll have to add some info there soon or later.

Meanwhile the info there is now can still be interesting for tuning the running parameters.

2010/4/12 jafo <jaf...@gmail.com>

--
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/

To unsubscribe, reply using "remove me" as the subject.