DTrace does allow for some very unobtrusive observation. Enabling every
fbt::: probe is always going to have a measurable effect on performance.
From what we know of the implementation of DTrace, it would seem very
unlikely that DTrace per se has changed the way the already broken PCFS
code behaves.
Rather, I suspect a latent race condition, the window for which is
opened once the code has been slowed down by the sledge hammer of
enabling every fbt probe.
Your experience doesn't undermine confidence in DTrace, it simply
underlines how complex systems are, and that we need to take things like
probe effect into account, no matter how small it may be.
Phil
Martin Cerveny wrote:
Hello,
What happens if you insert a "sleep 1" in the loop
between the mkdir and ls?
Error still exist with sleep or with mount/umount (with stable "dtracing side
effect"; not shown here):
# let i=0; while [[ $i -le 10 ]]; do mkdir .NET; sleep 1; ls -lad .NET; sleep
1; rmdir .NET; let i=i+1; done
.NET: No such file or directory
rmdir: directory ".NET": Directory does not exist
.NET: No such file or directory
rmdir: directory ".NET": Directory does not exist
.NET: No such file or directory
....
# cd ..
# let i=0; while [[ $i -le 10 ]]; do mkdir /mnt/.NET; umount /mnt; mount -F
pcfs $LOFIDEV:c /mnt; ls -lad /mnt/.NET; sleep 1; rmdir /mnt/.NET; let i=i+1;
done
/mnt/.NET: No such file or directory
rmdir: directory "/mnt/.NET": Directory does not exist
/mnt/.NET: No such file or directory
rmdir: directory "/mnt/.NET": Directory does not exist
...
M.C>
PS: I understand that there is the error in PCFS (I will probably find and correct the
problem), but I am very disappointed by "dtracing side effect" !!!! This breaks
non intrusiveness of dtrace.
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
