c0t0d0s0.org

I've just uploaded a new version of the "Less known Solaris features" ebook. As the IPMP tutorial is a part of the new document the page count reaches 379 now. You can download it at the usual location.

Roch Bourbonnais published an article about the new iSCSI framework in the S7000 series. Earlier versions of the S7000 firmware used the userland iSCSI daemon that was used in Solaris 10. Now the iSCSI functionality of the appliance is based on COMSTAR. This change is quite significant: Roch observed in a test an speedup by factor 2.7 as he states in "iSCSI unleashed". Really worth a read.

In the article about the new software version for the S7000 series i mentioned a feature called Shadow Migration. Eric Schrock wrote an interesting article about the inner workings of this feature in his blog: What is Shadow Migration?. I wonder if Solaris Engineering could use this work for a CacheFS follow-on .... at the end this would be not much more than a perpetual shadow migration plus the cache logic (LRU-stuff and consistency checking).

You will find a quiz on the english version of the Systemheros to find out something important about yourself, the name of our prefered OS or at least the one, where you found your admin socialization . Are you a chilly penguin or a sun worshipper?

Looks like Perl will have integrated dtrace support soon. The Install file of the Release Candidate 1 for Perl 5.10.1 http://search.cpan.org/dist/perl-5.10.1-RC1/INSTALL#DTrace_support">states:

On platforms where DTrace is available, it may be enabled by using the -Dusedtrace option to Configure. DTrace probes are available for subroutine entry (sub-entry) and subroutine exit (sub-exit). Here's a simple D script that uses them:

Ab nächster Woche habe ich erstmal drei Wochen Urlaub. Allerdings steht dem noch was im Weg Ich bin Samstag und Sonntag auf der FrOSCON 2009, die am 22. und 23.08. in Sankt Augustin stattfindet. Samstag helfe ich am Sun-Stand, Sonntag halte ich zusätzlich einen Vortrag: Insights to Opensolaris. Dieser startet am Sonntag um 17:45 in Hörsaal 4 und dauert etwa eine Stunde.

Charles Suresh published some interesting findings in "Improving MySQL/Innodb/ZFS read-only performance by 5x using SSDs for L2ARC". In this case he tried a workload with low locality, where just 5% of the blocks where reread again (thus showing cache-busting behaviour). Instead of a pretty minimal performance improvement (as suggested by theory) Charles got an performance improvement by factor 5.

At end this workload was one of this corner cases defying standard tuning knowledge. Normally you would match database block size and storage block size to get optimal performance. But this would hurt performance in this special case because the prefetching of ZFS wouldn't help as less data is cached. Cached? Yes, cached! ZFS doesn't cache just the mysql block you've used in this situation. That wouldn't be sensible. When you already have the data, you can cache them. Let's assume you have a 128 KByte blocksize and the 16 KByte blocksize. So you've read 8 blocks mysql-blocks with one ZFS block. Even in a cache defying workload there is a certain propability that even when you don't use block x again, you will use block x+1 to x+7 while it's in the cache. And this prefetch by mismatching blocksizes is largely responsible for the performance boost, where you didn't expected one. But: Without the mismatching blocksize you wouldn't have read this data into the cache, thus the system would have to go to the disk, thus resulting in lower performance.

Obviously the same effect is true for the normal ARC but as the ARC is normally much smaller than the L2ARC you have a high propability that the prefetched but unused mysql blocks are already evicted from the cache, when you need them. The larger cache provided the SSD reduces the propability that the data gets evicted from (L2)ARC before your workload uses the prefetched blocks.

I wrote about the logbias property for ZFS a few days ago in PSARC/2009/423 - ZFS logbias property. Last friday this feature had its flag day for Opensolaris build 122. So you will be able to try this feature to choose between latency and throughput oriented handling of the ZIL soon.

I received my new desktop/test rig/fileserver/sun ray server/internal webserver for my office at home today. I've ordered the wrong version of the case, so i have to purchase some additional fans tomorrow afternoon to complete the assembly. A first test install of OpenSolaris yielded no driver problems so far. Network detected, graphic card detected, sound detected. As some people asked me about my setup.

• Gigabyte GA-MA790XT-UD4P
• AMD Phenom II X4 905e (4x 2.5GHz) 4x512k
• be quiet! BQT P7-PRO 450W Dark Power PRO
• 4GB (2x2GB) Corsair XMS3 DHX DDR3-1333
• Zotac GeForce 9500 GT 1024MB PCIe
• Sharkoon Rebel12 Economy Edition Big Tower
• LG GH22NS30 22x DVD±R 10x/8x DVD±R DL 12
• Two Seagate ST3250318AS Barracuda 7200.12 250GB

For the IPMP tutorial i've integrated two e1000g into the system, but they were transplanted from a old system into the new one. Well, I will report about my tests and the further configuration in the next few days.

Jan Pechanec provides an interesting presentation about the enhancements to SunSSH and the OpenSSL version in Opensolaris in the period from January 2008 until June 2009. You can download it from mediacast.sun.com.

The moment is near where Solaris Express Community Edition will cease to exists in it´s current form. Glynn Foster announce Sun intent to do this in this mail at opensolaris-discuss:

Sun is announcing the intent to discontinue production of the Solaris Express Community Edition (SXCE) by the end of October time-frame. As we intend to continue on a bi-weekly build schedule, consolidations will move towards producing native Image Packaging System (IPS) packages alongside SVR4 packages and then phase out the latter completely. Technologies such as IPS, Automated Install, Snap Upgrade and the Distribution Constructor will be integrating into a consolidation after following through the established processes including architectural (ARC) review.

I think, this move is a good one, as long as this move gives us a new distribution that complies to all ARC decisions and has binary-compatibility by default at least in a container (yes, i'm from the "GNU tools behind Sun Tools in $PATH"- fraction. I hate to degnuing my system. When i want some of the comfortable niceties of GNU-Tools i'm able to modify the $PATH myself )

But at the end this is an necessary step: We´ve said that a distribution like OpenSolaris will be the future of Solaris. And Solaris Express is the development release for for Solaris release. So at one point in time you have to convert all the old distribution mechanisms to the new ones. And with this move this step will be made.

Update: You should read this article as well for some further information what this announcement really means.

The PSARC/2009/423 - ZFS logbias property is an interesting addition to the seperated ZIL functionality of ZFS. Not every synchronous write need the shortest possible latency, there are many write that are in need of throughput. And then there are synchronous writes that need so short latencies, that you want to remove all requests from a separated log, that doesn't need the help it.

With the logbias property you can control this behaviour. To stick with the example in the PSARC case: Redo Logs need short latencies, so you would use zfs set logbias=latency bigoracledataset/redologs. The data files of oracle need throughput, so you would configure zfs set logbias=throughput bigoracledataset/datafile. You don't have configure distinct pools (one with sZIl, one without it) to get the optimal behaviour). Furthermore the throughput mode makes another important change:

Also data will be written immediately to spread the write load thus making for quicker subsequent transaction group commits to the pool.

This article isn't really about a feature, it's about a directory and its misuse. Furthermore it's an article about different default configurations, that lead to misunderstandings. This is a pretty old hat for experienced Solaris admins (many of them learned it the hard tour), but it seems to be totally unknown to many admins new to the business or for people switching from Linux to Solaris, as many distribution are configured in a different way per default. A reader of my blog just found a 2GB .iso in /tmp on a Solaris system and that's not really a good idea. A few days ago, a user in twitter had vast problems with memory usage on a system which boiled down to a crowed /tmp.

While waiting for the first tea of this morning, I had an idea about updating OpenSolaris systems: Preemptive Updates. The idea is simple, but I assume many devils in the details of this idea. Let's assume you installed your system, you are satisfied with the selection of packages and all you do is just updating. Your system is somewhat fixed. You just update it from time to time. So you download fixes, you install them, and you reboot the system. There are many ways to shorten this process. MacOS X loads the updates in advance for example, so you don't have to wait a long time for the download, when the system notifies you of updates. But It should be possible to do more, to install the patches preemptively.

You know the problem: You are working on your system, edit a long config file and at the end you notice, that you have you didn´t acquired the necessary privileges to save the command. Dammed, saving to a temp file and copying it to a file would be a natural choice. But there is an easier way using pfexec. You find this trick at commandlinefu.com:

:w !pfexec tee %

There is an alternative for friends of sudo on the page.

(via commandlinefu)