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? Yours Markus Kovero
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
-----Original Message----- From: Bryan Cantrill [mailto:bmc at eng.sun.com] Sent: 22. helmikuuta 2010 17:47 To: Markus Kovero Cc: dtrace-discuss at opensolaris.org Subject: Re: [dtrace-discuss] Dtrace nfsv3-provider 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.> - BryanHi, I''m afraid this is not case and running find on fs this large is not viable option :/ is it possible that too little ncsize could affect this? Yours Markus Kovero