Re: Linux VFS cache hit rate script

[Jake Maul <jakemaul at gmail dot com>]

>> ERROR: Array overflow, check MAXMAPENTRIES near identifier '$file' at
>> /usr/share/systemtap/tapset/vfs.stp:769:9
>
> The error location looks bogus, which we should investigate, but this is
> probably from the array used in vfs.stp:__find_bdevname(). ?I'm not sure
> how you could be encountering so many unique "dev" though.

I made a quick test script- the only 2 devnames I run into are dm-0
and N/A on that system, and by far N/A is more common. However, this
test script fails pretty quickly (less than 5 seconds), with this
error:

# stap devnames.stp | sort | uniq -c
ERROR: probe overhead exceeded threshold
WARNING: Number of errors: 1, skipped probes: 0
Pass 5: run failed.  Try again with another '--vp 00001' option.
     41 dm-0
  55180 N/A


>> This is from the beginner's guide, actually:
>>
>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/SystemTap_Beginners_Guide/mainsect-disk.html
>>
>> It bothers me too, because I can't find any documentation that says
>> explicitly when you would get an 'N/A' devname. I don't know if it's a
>> SystemTap thing or a kernel thing, but being that I don't have
>> experience working on either, I'm fairly lost.
>
> That string comes from dev.stp:bdevname(bdev), whenever the parameter is
> zero. ?I'm not sure about the particulars though, whether bdev==0 really
> means it's a cache hit...
>
> Josh
>