This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Linux VFS cache hit rate script
On 04/21/2011 04:01 PM, Jake Maul wrote:
> 2 dev: 0 devname: N/A
> 762956 dev: 16 devname: N/A
> 520 dev: 18 devname: N/A
> 4183 dev: 22 devname: N/A
> 4 dev: 23 devname: N/A
> 1288 dev: 265289728 devname: dm-0
> 1 dev: 27 devname: N/A
> 872 dev: 3 devname: N/A
> 3094 dev: 5 devname: N/A
> 380875 dev: 6 devname: N/A
Oy - it's possible that the "dev" is meaningless (or means something
different) when the name is returned "N/A" (bdev==0), so we may be
caching noise as the index. Or in any case, caching "N/A" in so many
different forms is not helpful. Would you be willing to try this
modified function?
function __find_bdevname:string(dev:long, bdev:long)
{
if (bdev == 0)
return "N/A"
if (dev in __devnames)
return __devnames[dev]
return __devnames[dev] = bdevname(bdev)
}
> Both this script and the cache-hit-rate.stp script generally die with
> that error in 30 seconds or less. The data above is around 30 seconds
> or so.
>
> That bizarrely long dev number might be relevant... or maybe that's
> just a normal quirk of LVM?
It's not so bizarre - kernel device numbers are (MAJOR<<20)|MINOR, so
this turns out to be device 253,0. That also means all those low dev
numbers have MAJOR==0, which I think supports my theory that they are
not normal.
Josh