War is waging in the galaxy. This time it's not the Rebels against the Empire, or Good vs. Evil.

No, this war is different, and it has been going on ever since products designs companies entities existed.

What I mean is the war between Quality and Popularity.

Let me explain:

(Drumroll, Roman fanfare, then dramatic Anime action trailer a la Mortal Kombat, etc.)

As of May 21st, Google officially declared war on the Apple iPhone.

Sure, there was some teasing here and there for weeks, if not months, but this is serious.

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.

One of the web 2.0 startup hypes du jour is called Flattr. It's a micro-payment service that enables readers to allocate a monthly budget they can use to "flattr" blog posts and other content by clicking a simple badge. The monthly flat-rate is then distributed to the "flattred" authors as a way of appreciation.

More on that in this short video.

A lot of people are jumping on the Flattr bandwagon, and of course, rewarding creators is always goodness.

But I'm not convinced.

Why? Because IMHO there's no need for a middle man handling the "Thank You" transaction between a blogger (or other content creator) and the reader (or other content consumer).

Instead, here are ten (10) better ways to accomplish the same thing (supporting your favorite creator). They can involve money or not - you choose - and in each of them, everybody wins.

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.

A few weeks ago, we discussed using DTrace for automatically updating media servers when you upload new content.

Yesterday though, I discovered that my D script didn't work any more. I uploaded new songs to my home server, and expected the music daemon to re-scan the music directory, but nothing happened.

That teached me an important lesson about DTrace, and here's what I learned:

This is a long article, but I hope you'll still find it interesting to read. Let me know if you want me to break down future long articles into multiple parts instead.

One of the most frequently asked questions around ZFS is: "How can I improve ZFS performance?".

This is not to say that ZFS performance would be bad. ZFS can be a very fast file system. ZFS is mostly self-tuning and the inherent nature of the algorithms behind ZFS help you reach better performance than most RAID-controllers and RAID-boxes - but without the expensive "controller" part.

Most of the ZFS performance problems that I see are rooted in incorrect assumptions about the hardware, or just unrealistic expectations of the laws of physics.

So let's look at ten ways to easily improve ZFS performance that everyone can implement without being a ZFS expert.

During OSDevCon 2009 in Dresden, I had the honor to present on some lessons learned while putting together a ZFS Automatic-Scrubbing SMF service.

Today, Deirdre was so kind to publish the video recording of my presentation on The Oracle Solaris Video Blog.

From the description:

This talk walks you through the implementation of a simple SMF service. What sounds "simple" at first, develops a life of its own when you consider installation/de-installation, security considerations, error handling and debugging, and of course unexpected little bugs and shortcomings. Finally, we add a GUI to our service by discovering the OpenSolaris Visual Panels project. This "lessons learned" talk is intended to be a practical roundup of things to consider for developers interested in integrating with SMF.