I have written several times about the Solaris Leadvilel storage stack. While debugging a problem on a Solaris 9 host that wasn’t using the Leadville stack, I would wait and wait and wait for various commands to complete. Here is one such example:
$ timex /usr/openv/volmgr/bin/scan >/dev/null
real 2:25.09 user 0.10 sys 0.45
After migrating the same host to Solaris 10 and the Leadville stack, I no longer had to wait for my commands to complete. Here is an example:
$ timex /usr/openv/volmgr/bin/scan >/dev/null
real 0.11 user 0.05 sys 0.03
After doing a bit of debugging, I noticed that the Solaris 9 fibre channel stack (which was using a vendor supplied HBA driver) was enumerating each path to see if devices were present. In the Solaris 10 case (which was using a driver in the Leadville stack), the requests where satisfied from device nodes that were cached in the device tree. I wish I could prove this without a doubt, but unfortunately I can’t run Chris’ awesome scsi.d DTrace script on my Solaris 9 host. If one of the Sun storage engineers happens to come across this blog entry, please leave me a comment with your thoughts.