I was aware of that suggestion but found it so ugly that I never tried it. I
ditched pride and embraced pragmatism. And yes running find did resolve all
names. Could you be so kind and trouble the gentleman down the hall and ask
them what's happening and why? Perhaps something can be done about it
plus virtualbox 4.1 with "network in a box" would like snv_159
from http://www.virtualbox.org/wiki/Changelog
Solaris hosts: New Crossbow based bridged networking driver for Solaris 11
build 159 and above
Rob
___
zfs-
I've had issues like this as well. Fortunately Eric Schrock and Adam
Leventhal work down the all from me and I ran this past them. Eric had the
suggestion to simply do a "find" from the directory that I'm interested in
getting file names for and that did the trick. For example all of my tracing
is
On Mon, Jul 18, 2011 at 6:21 AM, Edward Ned Harvey
wrote:
> Kidding aside, for anyone finding this thread at a later time, here's the
> answer. It sounds unnecessarily complex at first, but then I went through
> it ... Only took like a minute or two. It was exceptionally easy in fact.
> h
On Wed, Jul 20, 2011 at 7:10 AM, wessels wrote:
> I'm issuing the following statement on a ONNV_104 (I know a bit old
> but very stable) NFS server:
> # dtrace -n 'nfsv3:::op-read-start,nfsv3:::op-write-start
> {@[probefunc,args[1]->noi_curpath]=count(); }'
>
> which works fine...most of the time
Hi,
I'm issuing the following statement on a ONNV_104 (I know a bit old
but very stable) NFS server:
# dtrace -n 'nfsv3:::op-read-start,nfsv3:::op-write-start
{@[probefunc,args[1]->noi_curpath]=count(); }'
which works fine...most of the time but not always.
Usually it resolve's the filenames on w
