Peter,
You mentioned you're seeing different behavior on snv_54 and
s10u3. Are this different systems is it the same hardware
running different OSes at different times?
If you would, would you run the following and send me the output?
You can send it directly to Rich.Brown at Sun.COM
df /
fsid / # See attached fsid.c
fsstat -f /
kstat | grep vopstat
Thanks,
Rich
Peter Tribble wrote:
> Rich,
>
> Peter Tribble wrote:
> > I've been using fsstat (glad to see it made it into update 3!) a
> little.
> >
> > I've stumbled across bug 6508225, which I see on a nevada box.
> > I'm seeing a related problem on S10U3 - instead of claiming there
> > aren't any statistics for /, most of them are just zero with SVM
> > root. This is particularly annoying as I don't believe in having
> > more partitions that I need, so if I can get away with just a
> > large root partition then I will.
>
> Are you looking at the kstats directly or is fsstat reporting
> mostly zero numbers for "/" (on an SVM device).
>
> If you're looking at the kstats directly, then these are "zombie"
> kstats due to 6508225.
>
>
> That's what I see on snv_54:
>
> % fsstat /
> No statistics available for /
>
> On S10U3 I see mostly zeros:
>
> % fsstat /
> new name name attr attr lookup rddir read read write write
> file remov chng get set ops ops ops bytes ops bytes
> 0 0 0 362K 0 0 0 0 0 0 0 /
>
> I get essentially the same out of jfsstat, which looks at the raw kstats.
>
> > Another observation: I notice that the kstats are generated for
> > all the entries in a direct automount map, even though none
> > of the filesystems are actually mounted. Is this desirable?
> > (I've checked, and it doesn't seem to keep historical data -
> > the values seem to reset if a filesystem is mounted or
> > unmounted.)
>
> Hmm... Sounds like you found a bug where the kstat isn't cleaned
> up when the file system is unmounted. Would you please submit
> a bug report on this?
>
>
> I don't think that's it. The kstats are cleaned up when the real filesystem
> is unmounted (at least, they're reset); the question is why there's a
> kstat for every underlying autofs mount? And, because the dev id doesn't
> change, it can get very confusing:
>
> - there's a kstat associated with an autofs mount that is just a
> placeholder
>
> - when the real filesystem gets mounted the kstat has the same
> name
>
> - when the real filesystem gets unmounted, there's still a kstat
> with the same name but with zeroed data
>
> It just seems inefficient. And my scheme of simply looking for new kstats
> to appear to spot new filesystems being added doesn't work.
>
> Ultimately, should autofs mounts have fsstat kstats?
>
> --
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fsid.c
Type: text/x-csrc
Size: 730 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/observability-discuss/attachments/20070111/a1112e76/attachment.bin>
