opensolaris

My last post about Solaris 11 triggered an interesting discussion with UX-admin about IPS and the lack of pre-/post-scripts for installation/removal.

Assuming that Solaris 11 will be based on IPS just like OpenSolaris, it is certain that sysadmins will have to change a lot in how they create and manage packages, because IPS is fundamentally different from the good old System V packaging system.

So let's explore the lack of scripting hooks in IPS and see if we can find some ways of working around them:

Lots of speculation about Solaris and OpenSolaris is happening right now, with an allegedly leaked email being the latest generator of buzz, rumors and troll-ism.

But is that any useful? No.

So let's cut through the shiitake, do some due diligence and focus on some real facts instead.

In this article, we'll check out some real and authoritative sources of Solaris direction, mainly John Fowler's recent webcast about Solaris 11. Then we'll see what our future opportunities as members of the Solaris community are, and close with some pointers to other opinions on Solaris 11.

When talking to customers, partners and colleagues about Oracle Solaris ZFS performance, one topic almost always seems to pop up: Synchronous writes and the ZIL.

In fact, most ZFS performance problems I see are related to synchronous writes, how they are handled by ZFS through the ZIL and how they impact IOPS load on the pool's disks.

Many people blame the ZIL for bad performance, and they even try to turn it off, but that's not good. Actually, the opposite is true: The ZIL is there to help you.

In this article, we'll learn what synchronous writes are, how they're processed by ZFS, what the ZIL is, how it works, how to measure ZIL activity and how to accelerate synchronous write performance, which is at the root of many, if not the majority of ZFS performance problems.

One of the best information sources for any topic are blogs, and the Oracle Solaris operating system in all its variants (Solaris 10 and OpenSolaris) is no exception. Most of what I learned about OpenSolaris was through blogs, or through interacting with Solaris bloggers.

As a way of saying "Thank You", I did some research and came up with a list of the top ten Solaris related blogs with the highest traffic on the Internet.

But first, let's clear up some basic rules.

The developers of ZFS are a funny bunch of people. You can tell that by watching the "ZFS: The Next Word" talk, meeting them on conferences, reading their blogs or their comments on mailing lists.

And there are also some funny parts in the ZFS source code, too. In fact, if you use ZFS, you'll have a funny joke sitting on your disk, right under your nose!

I was reminded about this particular joke while listening to Ulrich Gräf's excellent talk on ZFS internal data structures during OSDevCon 2009 (watch a video of Ulrich's talk here).

But first, we need to dig a little bit into the world of ZFS data structures.

When looking at the mails and comments I get about my ZFS optimization
and my RAID-Greed posts, the same type of questions tend to pop up over and over again. Here's an example from a reader email:

"I was reading about ZFS on your blog and you mention that if I do a 6 drive array for example, and a single RAID-Z the speed of the slowest drive is the maximum I will be able to achieve, now I thought that ZFS would be better in terms of speed. Please let me know if there is a newer ZFS version that improved this or if it does not apply anymore."

This is just an example, but the basic theme is the same for much for the reactions I see: Many people think that RAID-Z will give them always good performance and are surprised that it doesn't, thinking it's a software, an OpenSolaris or a ZFS issue.

In reality, it's just pure logic and physics, and to understand that we should look a little closer at what vdevs are in ZFS and how they work.

In the last couple of posts, we used DTrace to notify our media servers and perfected our script a bit.

But the script is still not ready to be used on our home servers yet: It requires manual start and stop, not quite the service oriented automatism we're used to in the Oracle Solaris world.

The next step is to wrap our DTrace script inside a Service Management Facility (SMF) service, then wrap everything into a shell script that will easily install or remove the service whenever we need it.