On Mon, Feb 22, 2010 at 02:00:58PM +0200, Markus Kovero wrote:
> Hi, I'm clueless why dtrace nfsv3 provider gives pathname <unknown> in almost
> 90% of fileops with op-write/read-start and op-write/read-done probes.
> Documentation states this should be rare event, in this case it seems to be
> more default behaviour. Any ideas?
Is it possible that clients had open file handles across a server reboot?
If this occurs, we have no way of getting path information, as no lookup
was ever performed (from the server's perspective). This is an annoying
issue with no real prospects for resolution: without storing the path
information persistently in the per-file metadata (a notion that is clearly
fatally flawed), there is no way to get from a file handle back to a
path that will resolve to that file. The only glimmer of hope is that
successful lookups _will_ result in the restoration of in-core path
information -- so if you can somehow perform a manual lookup that happens
to correspond to the file handle(s) being accessed, your path information
will start showing up. So in the worst case, you can get your paths back
by performing a find(1) on shared filesystems -- and yes, it's awful.
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
