0

From here http://wikis.sun.com/display/DTrace/nfsv3+Provider

on OpenIndiana

the DTrace scripts:

  • nfsv3io.d
  • nfsv3ops.d

are failing with:

probe description nfsv3:::op-* matches an unstable set of probes

Script nfsv3fileio.d works but one of the lines with very large Rbytes and Wbytes has the Pathname as 

<unknown>

Does anyone know any details on these failures and what are the workarounds?

Aleksandr Levchuk
  • 2,415
  • 3
  • 21
  • 41
  • This question is a follow up to this answer: http://serverfault.com/questions/304682/solaris-nfs-which-client-is-all-the-traffic-comming-from/304697#304697 – Aleksandr Levchuk Aug 25 '11 at 03:23

1 Answers1

4

The first script fails because the example is incorrect. You can't reference args[] while globbing the probe in that manner (as probes matching the pattern may come and go while the enabling is still in effect, so guarantees about the type of args[N] can't be made). You'd need to list each nfs3-op-* individually, comma separated nfs3:::op-read-start,nfs3:::op-write-start etc, for each operation you care about.

For nfsv3fileio.d the Rbytes and Wbytes of "unknown" are very large, because they're the sum of all I/O to unknown paths (probably several, perhaps many).

The paths are <unknown> because the kernel only stores path information in the vnode lazily (if it happens to be present, it's stored, but it's not actively sought out). And as such is not always available. There are tricks that sometimes force it into place (I seem to recall that find across the FS in question should do it, but my memory could be playing tricks).

richlowe
  • 61
  • 2