Tuesday, March 01, 2005

:: Reviews : First Look At Solaris 10

:: Reviews : First Look At Solaris 10:

Sun Microsystems has recently released Solaris 10. It is currently free, as in beer, and most of it is promised to be released under an OSI approved license in the second quarter of 2005.

Excerpts from the article which is very infomative. Full article read is suggested.
One of the main new features in Solaris 10 is DTrace, a dynamic instrumentation system. DTrace consists of a
scripting language, named D (not to be confused with the fledgling D Programming Language), and loadable kernel modules named “providers.” When called upon, these “providers” track and report system information. DTrace has several
features that separate it from other similar systems:
  • It is dynamic. DTrace has no effect on system performance when not in use. Only those providers that are needed by a particular command are loaded and used. This means if you want to collect data on the scheduler, DTrace will not be collecting data on the IO system as well. This greatly improves performance over those systems that collect a huge
    amount of unneeded data.
  • It can instrument both the kernel-level and user-level.
  • It is safe. DTrace will not allow you to damage the system through its use. Some may find the idea of anything being “totally safe” rather amusing. However, this appears to be true. Time will tell if it holds up, but for the moment I
    have no evidence to the contrary.
  • It is adaptable. DTrace really is more a scripting language then it is a tool like truss or top. This has its downside and upside. The disadvantage is that it is not a small thing to learn. Most will probably never use DTrace
    directly, but instead use programs written in D. There are already some of these and there will eventually be many more. The advantage to this is that its not limited like top or truss. Supposedly the test of a well-designed program is that people use it for things the author never thought of. DTrace passes this test with flying colors.
DTrace will inevitably be compared to similar systems. These include The Linux Trace Toolkit (LTT) and Dprobes. These systems may grow into something equivalent to DTrace, but at the moment they are not even close. LTT is not dynamic and has only around 45 points of instrumentation to avoid a large performance penalty. Comparing that to Dtrace:
    # DTrace -l | wc -l

Dprobes is much more advanced, but has problems as well. It is dynamic, but lacks some of the advanced
features of the D language and is not safe. You can definitely bring down a machine with a badly written Dprobes script. It also supposedly performs poorly on multiple CPUs.

One interesting DTrace script I found is seeksize.d. This script tracks the offset value of seek requests to the discs, per
process. I have never been able to see this information before and it is really quite interesting, although somewhat shocking. The script was written by Brendan Gregg, who has produced many DTrace scripts that review system information from shell use to socket statistics. [http://users.tpg.com.au/adsln4yb/dtrace.html]


If you have used FreeBSD Jails, Solaris Zones are going to sound very familiar. They are based on the same
basic concept. Both can be considered somewhat like a heavy-duty chroot. Each Zone or Jail is a virtual OS, complete with IP address, separate configuration and even a separate package DB (zones can also share a DB). Now, this may seem like exactly what UserModeLinux or Xen do, but it isn't. The difference is that all the Zones/Jails share one

In Xen or UML, the sub-machines are full OS's, kernel and all. They run on vm-like layer over the actual kernel. The advantage to this is security; it is very difficult to break out of a virtual server setup in this way. The disadvantage is speed; running all these different kernels has a large performance hit. This is why FreeBSD Jails were thought of in the first place and Sun has gone that direction with Zones.

It is theoretically possible to break out of a Jail or Zone. In fact, there have been security vulnerabilities in the past that allow
processes to do just that. It is of course up to the System Administrator to balance these issues. Personally, I would rather be
able to run a large number of Jails/Zones and take the minimal security risk.

Service Management Framework

SMF (The Service Management Framework)
is Solaris 10's replacement for the aged sysV init. I have mixed feelings about SMF. It is definitely a step forward, but it adds a
level of complexity that was not there before. The idea behind it is fairly simple and SMF can be logically split into several parts:
  • Startups scripts. These are very like the normal scripts you see in every UNIX implementation
  • XML manifests. This is where things get different. Every service has an XML file that holds
    information about the service. What other services does it depend on? What services does it not depend on, but are recommended? All these relationships and more are stored in the manifests.
  • svcs. The svcs command is one of the main interfaces to SMF. It can tell you what services are
    started, which are stopped and even what services failed to start and why. For example, if service A depends on service B and you have stopped service B, svcs might tell you that service A has failed
    because service B is stopped.
  • svcadm. This is the administrative tool for SMF. You can add, delete, stop and start services here.
  • init. The init systems works a bit differently on Solaris 10 because of all this. If a service fails to start or crashes, it will be restarted. Also, if you stop a service that another service depends on, that service will also be stopped. Likewise, if you start a service that depends on several others, they will all be started. Also, the dependency system allows
    init to start multiple services in parallel.
My concern about SMF is that its not as transparent as a system like rc.d on NetBSD/FreeBSD or even the old sysV init. It is still fairly easy to understand, but there is a level of “magic” that wasn't there before. Maybe my concerns are baseless? I don't know. It will be interesting to watch how users react to the new system.

Along with new features, there have been improvements made to the general OS, many having to do with speed. Solaris has been given the nickname “Slowlaris” in the past. With Solaris 10, Sun has worked hard to make that name no longer applicable.


Solaris 10 is a rather amazing OS. I learn quickly, but I was hard pressed to even tap the surface of Solaris. It is very fast, has new features that are revolutionary and old features that are not very well known, but deserve to be. Its hardware support could, and I think will, be improved, some software will be difficult to compile and it can be difficult to use at times when coming from other NIX. However, any relatively knowledgeable user should give it a shot. You may be impressed.

No comments:

Post a Comment