I have spent a fair amount of time in the past few weeks reading through RFC 1813 (NFSv3), and wanted to find a way to see if a given client operation resulted in a physical or logical I/O operation. Since the DTrace FBT provider allows you to observe entry and exit from 99.999% of the functions in the Solaris kernel, I decided DTrace would be ideal for answering this question. After reading through the vast majority of the NFSv3 client source code on opensolaris.org, I crafted a DTrace program named nfstrace to display NFSv3 client operations by process:
$ nfstrace
Executable Operation Type Time Size Path
mkdir nfs3_lookup physical 359953 N/A /opt/nfs/htdocs/test
mkdir nfs3_getattr logical 17481 N/A /opt/nfs/htdocs/test
mkdir nfs3_getattr logical 7577 N/A /opt/nfs/htdocs/test
mkdir nfs3_mkdir physical 843500 N/A /opt/nfs/htdocs/test/test
rmdir nfs3_access logical 19772 N/A /opt/nfs/htdocs/test
rmdir nfs3_lookup logical 69222 N/A /opt/nfs/htdocs/test/test
rmdir nfs3_access logical 7744 N/A /opt/nfs/htdocs/test
rmdir nfs3_rmdir physical 1390474 N/A /opt/nfs/htdocs/test/test
touch nfs3_access logical 19566 N/A /opt/nfs/htdocs/test
touch nfs3_lookup logical 68824 N/A /opt/nfs/htdocs/test/1
touch nfs3_getattr logical 17842 N/A /opt/nfs/htdocs/test/1
touch nfs3_access logical 7746 N/A /opt/nfs/htdocs/test
touch nfs3_lookup logical 26527 N/A /opt/nfs/htdocs/test/1
touch nfs3_setattr logical 597203 N/A /opt/nfs/htdocs/test/1
ln nfs3_lookup physical 299999 N/A /opt/nfs/htdocs/test/2
ln nfs3_access physical 20033 N/A /opt/nfs/htdocs/test
ln nfs3_lookup physical 222977 N/A /opt/nfs/htdocs/test/2
ln nfs3_access physical 9553 N/A /opt/nfs/htdocs/test
ln nfs3_lookup physical 222109 N/A /opt/nfs/htdocs/test/2
ln nfs3_symlink physical 899939 N/A /opt/nfs/htdocs/test/2 -> /opt/nfs/htdocs/test/1
cat nfs3_access logical 19528 N/A /opt/nfs/htdocs/test
cat nfs3_lookup logical 67471 N/A /opt/nfs/htdocs/test/2
cat nfs3_access logical 7722 N/A /opt/nfs/htdocs/test
cat nfs3_lookup logical 26941 N/A /opt/nfs/htdocs/test/1
cat nfs3_access physical 278486 N/A /opt/nfs/htdocs/test/1
cat nfs3_getattr logical 17554 N/A /opt/nfs/htdocs/test/1
cat nfs3_read logical 54848 8192 /opt/nfs/htdocs/test/1
cat nfs3_read logical 10082 8192 /opt/nfs/htdocs/test/1
bash nfs3_access logical 19707 N/A /opt/nfs/htdocs/test
bash nfs3_lookup logical 66602 N/A /opt/nfs/htdocs/test/.
bash nfs3_access logical 7740 N/A /opt/nfs/htdocs/test
cp nfs3_write physical 38821 3935 /opt/nfs/htdocs/test/99
The script leverages the fact that each file system implements a set of operations call VOPS (VNODE Operations), which are called by the Solaris kernel in response to a system call that operates on a file or directory in a given file system. In the case of NFSv3, when you issue a read(2) system call, the kernel will determine that the operation applies to a file on an NFSv3 share, and will invoke nfs3_read, which is the NFSv3-specific read routine. For further details on VNODE Operations, VFS and the NFS implementation, I will refer you to Solaris and UNIX internals.
Over the past few months, I have been spending part of my free time listening to podcasts on investing. The vocabulary used on wall street is super interesting (I am a finance major, so I love this stuff), and includes fun words like LEAPS, DRIPs, oscillators, breakouts, resistance, support lines, asset classes, and a whole slew of other interesting terminology. To make sense of all this market speak, I have been referring to the Trader’s Glossary A-Z. If you need to figure out wall street terminology, this is a great place to start.
I came across the following post that discusses some of the thermal issues currently found in the macbook pros. According to the poster, Apple (or their suppliers) is incorrectly applying thermal paste to the CPU dies in the macbook pros, which is leading to higher than expected operating termperatures. The picture he presents from one of Apple’s training manuals is amusing, and if they are following the suggestion in the picture, they are clearly misappropriating thermal grease. Great post, and good analysis!
While surfing the web this weekend, I came across the following procedure for reinstalling grub from the command line:
1. Boot the system from an installation boot medium.
2. Type linux rescue at the installation boot prompt to enter the rescue environment.
3. Type chroot /mnt/sysimage to mount the root partition.
4. Type /sbin/grub-install /dev/hda to reinstall the GRUB boot loader, where /dev/hda is the boot partition.
5. Review the /boot/grub/grub.conf file, as additional entries may be needed for GRUB to control additional operating systems.
6. Reboot the system.
This is useful stuff, and having it handy can save you time you get into a bind.
I just came across the objdump “–source” option, which will display the C source code from a program along with the assembly instructions that were generated from the C code. The following example shows a snippet of what is produced during a typical run:
$ objdump --source curl
08050ed0 <homedir >:
char *homedir(void)
{
8050ed0: 55 push %ebp
char *home;
home = GetEnv("CURL_HOME", FALSE);
8050ed1: 31 d2 xor %edx,%edx
8050ed3: 89 e5 mov %esp,%ebp
8050ed5: b8 01 d0 05 08 mov $0x805d001,%eax
8050eda: 53 push %ebx
8050edb: 83 ec 04 sub $0x4,%esp
8050ede: e8 bd ff ff ff call 8050ea0
if(home)
8050ee3: 85 c0 test %eax,%eax
8050ee5: 89 c3 mov %eax,%ebx
8050ee7: 74 08 je 8050ef1
return home;
This is neat!