There are a few gotchas that I find somewhat annoying.

• The clutter interface, while cool, does seem a bit buggy. Sometimes the zones (virtual desktop) switcher seems to change size and does the wrong thing.
• The clutter version of Firefox will sometimes have ‘focus’ issues and not work exactly right. I did install regular firefox and that seems a good deal better.
• Would be nice if it supported “themes” a bit better so that the UI was more customizable.
• They still have an older XFCE desktop package set, but no reasonable way to simply switch to it.

Overall, I do recommend Moblin for use on the MSI Wind. It’s not 100% polished yet, but it’s getting there very quickly. I gave it about a day booted from USB doing their test drive before installing it on the HDD. (Thank you MSI for shipping XP on a smaller partition and leaving the rest of the disk free for this kind of thing.)

On a sidenote, I’m sure this is listed somewhere else, but one thing I noted was that the swap space is pretty small by default with OpenSolaris, so I just did a

zfs set volsize=2G rpool/swap

and I was good to go with a reasonable amount of swap.

A few things stand out

• The package manager is quite usable now. There’s clearly been some improvement in the speed at which it runs and the general search and install capabilities are very reasonable. One might even say better than your average Linux’s capabilities in this respect. Also, the sheer number of packages has increased substantially. Good to see things like Eclipse there.
• Fast Reboot is a very cool feature. I could see some positive implications on the server side for this.
• A number of laptop improvements are available, though this is not terribly obvious within VirtualBox. When I load it up on the Ferrari, it should make the experience even better.

It seems like the general stability/usability (updated Gnome, for instance) of OpenSolaris 2008.11 shows that this could very well be a good desktop OS. As mentioned earlier, I’ve run Solaris as a desktop OS for quite some time, but it’s never been a particularly “easy” experience, with plenty of self compiling (or with the excellent SFE), but OpenSolaris really has brought a lot of ease to the process.

The issue I recently ran into was that I had forgotten to update the process.max-file-descriptor before starting up a service, only to find it had run out of FDs. I applied the fix to /etc/{user_attr,project} but didn’t want to restart the app to have it take effect, so I used the plimit(1) command, something like:

plimit -n 4096,8192 `pgrep procname`

So, it’s set for now, and when the process dies/restarts, it’ll pick up the right stuff from /etc/

Start Both Services


svcadm enable svc:/application/management/snmpdx:default
svcadm enable svc:/application/management/sma:default


According to Sun’s Documentation, snmpdx should be running before sma starts. By default, snmpdx is listening on port 16161 which won’t be queried by snmpwalk or snmpget. Starting sma will give you the default 161 listening snmpd. Each one has a different config file. sma’s configuration is found under /etc/sma/ while snmpdx’s is found under /etc/snmp, so it’s fairly important to keep track of where you’re making your changes. /etc/snmp seems like a pretty logical place to go and edit files, but most likely you’re never going to need to touch them.

Test It Out
It’s fairly easy to test it. Because Net-SNMP will answer SNMP v1, 2c and 3 queries, you can do some fancy stuff like setup authentication with v3. For the default config, you can simply run:

snmpwalk -v 2c -c localhost public


This should return quite a few lines regarding your system. You can use more specific calls like:

$ snmpget -v 2c -c public localhost 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: SunOS thor 5.10 Generic_137112-02 i86pc

Which will give you the output of uname -a. As you can see from the output, the OID has been converted to a more reasonable string by the MIB, so 1.3.6.1.2.1.1.0 is the same as:

$ snmpget -v 2c -c public localhost sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: SunOS thor 5.10 Generic_137112-02 i86pc

You can poke around in /etc/sma/snmp/mibs/ for more more useful data.

Sun’s documentation is typically pretty good and they cover some of this in:
http://docs.sun.com/app/docs/doc/817-3000/introduction-5?a=view
It’s a little densely packed, but it can get you going and explain much better what SNMP agents are and why there’s snmpdx, etc.

I’ve had the opportunity to beta test the Sun Fire X4540, which is the successor for the highly acclaimed Sun Fire X4500 (aka thumper). For those of you who haven’t heard of the thumper, it’s a 4U 48 drive system that more or less combines a head unit plus disks to form an all-in-one file server in a very compact design. While it likely could run any number of operating systems, it’s particularly well designed for Solaris 10 or OpenSolaris and ZFS, as the disks are presented JBOD style.

On the technical side, the X4540 addresses some of the initial issues I had with the X4500, primarily support for a great deal more RAM (from 16 to 64), which means that ZFS will cache even more efficiently than ever and you can run a larger variety of memory hungry apps if you’re so inclined. It also supports the newer AMD Opteron 2xxx CPUs, so you get not only better speed, but also the energy savings associated with use DDR2. In addition, there’s also a CF slot on the back so that you can boot the system without wasting one or two of the 48 drives.

Unfortunately, there are a couple of downsides to the new system, which might just be me being picky. First, they’ve decided to use the NVIDIA ethernet controllers, which I’ve had problems with in the past. (In their defense the problems are fixed in U5, though not in U4.) It would have been vastly preferrable for them to use the tried and true Intel E1000G controllers as found on many of their systems. I don’t know about everyone else, but I’m of the opion that those are the best gigabit ethernet controllers available. In addition to the use of nge vs. e1000g, there’s still the basic issue of wasting drives for booting. Yes, CF is an interesting way to go, but I believe it would have been nice if they had found a way to cram a couple of small SSD drives in there so you could mirror and boot off of those, so if for some strange reason you wanted more performance on you systems disks (heavy logging, maybe?), you could do that.

Performance-wise the thing is a beast. There’s no doubt that the system performance is pretty amazing. I used a combination of iozone, bonnie++ and FileBench to generate load on the system in order gauge performnance. For large sequential writes and reads, getting close to 1GB/s across all of the drives was fairly easy. Smaller, random performance wasn’t quite as out of this world, but still quite good (500+MB/s).

The actual system specs were:

• 2 Quad Core Opteron 2356s
• 32GB of RAM (16 2GB DIMMs)
• 48 1TB drives

I created 4x 9+2 (raidz2) pools. I’ve heard rumors that building zpools with greater than 10 drives is a mistake, but it was the best performance to space ratio I could make work reasonably. One thing I’ll note is that it’s probably a good idea to build your pools out across as many of the internal controllers as possible to try and maximize parallelism in your data.

Here’s some bonnie++ data showing all 4 zpool results (they were running in parallel):
pool0:
Version 1.03c ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
thor 64G 100520 98 207778 66 108533 49 81102 90 249018 63 836.6 8
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
thor,64G,100520,98,207778,66,108533,49,81102,90,249018,63,836.6,8,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

pool1:
Version 1.03c ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
thor 64G 104081 97 255887 56 104614 44 79642 87 259304 59 908.2 13
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
thor,64G,104081,97,255887,56,104614,44,79642,87,259304,59,908.2,13,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

pool2:
Version 1.03c ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
thor 64G 100374 98 194312 66 110581 48 81316 90 259698 63 876.7 4
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
thor,64G,100374,98,194312,66,110581,48,81316,90,259698,63,876.7,4,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

pool3:
Version 1.03c ——Sequential Output—— –Sequential Input- –Random-
-Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
thor 64G 104064 97 223351 50 104265 43 82014 88 257469 60 982.6 11
——Sequential Create—— ——–Random Create——–
-Create– –Read— -Delete– -Create– –Read— -Delete–
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ 32464 88 +++++ +++ +++++ +++
thor,64G,104064,97,223351,50,104265,43,82014,88,257469,60,982.6,11,16,+++++,+++,+++++,+++,+++++,+++,32464,88,+++++,+++,+++++,+++

Closing

I’d say the system is a really nice bulk storage device for a great price. Performance is quite reasonable (it’s no 15k RPM SAS) for the size and would make an excellent fileserver, backup host or iSCSI target for who knows what.