c0t0d0s0.org

Okay, there is a beautiful icing on the sulfur seas in hell. You find a video of an OpenSolaris kernel boot into something similar to the single user mode on a zSeries at youtube: Part IV and Part V. The boot starts at the end of Part IV.

Looks like a good solution for the problem of naming the reference OpenSolaris distribition without alienating the developers of other Opensolaris distributions - An Open Letter to the Community: A Proposed Solution:

For the community, OpenSolaris RD is clearly delineated, drawing on the OpenSolaris brand but being distinct at the same time.
For Sun, this provides a clear, hip, conventionally accepted naming scheme that is extensible over time. Taking up the name "OpenSolaris" alone is short sited. Because of the nature of the distribution a fully supported version will need to be created for ISV Qualification, etc, down the road. This qualified version will be a customized version of OpenSolaris RD and perhaps named OpenSolaris GS ("Genric Server") or OpenSolaris DS ("Data Server").

Hallo Kai,

Ich habe mich gefragt, was ich zu deinem "Text" zum Thema Opensolaris schreiben soll, der dann doch einfach und umgreifend daran leidet, das Du dir bei einigen Dingen noch nicht ganz der Tragweite bewusst bist, die ein einzelnes Faktum besitzt, in vielen Dingen Themen verkuerzt und Fakten weglaesst (ich mag das Wort "absichtlich" nicht in diesem Satz verwenden auch wenn ich den Gedanken hatte). An vielen Stellen ist die Argumentation einfach nur krude. Eigentlich gebe ich damit deinem "Text" mehr Aufmerksamkeit als er verdient, aber ich denke daran lassen sich viele Dinge festmachen, die mich in der Diskussion mit Linux und der Klarstellung "Wozu Opensolaris?" nerven. Vielleicht fang ich einfach mal an, einige Dinge klarzustellen:

Nice review of OpenSolaris Developer Preview at Phoronix:

After using the Project Indiana / OpenSolaris Developer Preview for the past couple of hours, we are already confident in saying that this is the most consumer-friendly Solaris-based distribution to date (even more so than Nexenta OS or BeleniX).

Not bad for the first release ....

The first results of the Project Indiana are now available to the public. (For starters: Project Indiana is a project to create an OpenSolaris Binary Distribition that uses the same distribution model as for example Debian Linux. It´s the emancipation of the distribition from the linux kernel. You will find a glowing plea for this project in Ben Rockwoods blog) You will find a Live CD environment on the community page of the project. You can run it directly from CD or install it to you hard disk. Looks promising, i think i will give it a try this weekend ...

PS: As this is the public prototype, there are some limitations. Plese read them, before you try an installation to your HD.

Many customers ask : What the heck is Project Indiana?". I tend to say as a short Version "The emancipation of the network distribution model from Linux with all the inherent advantages. " Ben Rockwood seems to have the same opinion and wrote an excellent and blazing plea for Project Indiana: What Is Project Indiana? Explained:

What is Project Indiana? Ambiguity where there is none. Possibility where there is constraint. Openness where there is little or none. A fresh start, on a clean sheet, whereby we can explore the full potential of what Solaris could be, can be, and should be.

Andrew Leventhal and Brendan Gregg gave an interesting presentation how DTrace can help you to find nasty performance problems in your software (and how dtrace helped Twitter to find performance problems).

One of the hurting annoyances of ZFS was the problem, that Samba wasn´t able to set and get ZFS access control lists. This even led to a lost project in one of my accounts. But the end of the suffering is near: 2149388 - Samba ACL interaction with NFSv4 and ZFS does not work - fix delivered or 6576479 - Handling of the special ace's in samba vfs module vfs_zfsacl need fix - fix delivered

I´ve reported about the separated ZIL a few days ago. The problem of the described NVRAM PCI card is, that you can´t do a clusterfailover with such a device. How do you want to failover the seperate log, when the log is on a card in the failed server? Sun had a product called Prestoserve, that was used to accelerate NFS and DB. It was static RAM with a battery. It was great for benchmarks, but suffered by the cluster problem.

Thus you should use some external device, that can failover with the rest of your storage. The obvious choice would be a RAM-based Solid State Disk(SSD). But these are quite expensive: You need the RAM, you need a harddisk to keep the data persistent when power fails, and you need a rechargeable battery or an capacitor that´s able to power the SSD until all data is written to the hard disk.

A Flash-Based SSD would be a more sensible choice, as Flash is a non-volatile memory by nature. Such a disk costs you approximatly 400$. But most people think "Oh no, wear will destroy it within a few days". Experiences with el-cheapo CF-cards underline this assumption.

But let´s calculate with the specifications of a leading brand flash disk. Let´s assume: A 32 GB flash-based SSD is specified for 2.000.000 write cycles. We have a sustained stream of 40 MB per second (conservative assumption). The wear leveling is perfect (perhaps supported by a seperate ZIL algorithm, that looks at the flash SSD as a cyclic buffer). Okay, a little math:


So this flash SSD wouldn´t fail by wear within the usable live of the storage and the server, even when you write 40 MB every second to it. I´m sure, that a flash disk doesn´t run such a long time, but this is not a wear problem, it´s the problem, that modern electronic hasn´t the build quality of former times.

Based on this considerations, a flash SSD would be an interesting choice for the separated ZIL. Or at least: Wear isn´t a reason for not using Flash SSD

PS: There is one point, i´m not perfectly sure, but i interpret the 2 million write cycles as the ability to erase and write the full disk 2 million times.

It was quite a while in beta status, but now it´s available: Flash9 for Solaris 10. It will be part of Opensolaris with Build 69.

There is an additional provider for monitoring your system: The DTrace provider for iSCSI.You will find a nice bunch of D scripts at the Solaris Internals Wiki, ranging from iSCSI snoop to measuring latencies in iSCSI operations

That´s really a neat new feature. The code of CR6339640 was commited to Opensolaris: With the corresponding changes to ZFS you can place the intent log separate from your data disks, for example to NVRAM devices .This will vastly speed up some write operations and eliminates the last advantage of NetApp WAFL.

Ben Rockwood of cuddletech made a presentation about Opensolaris at the JavaOne. Based on the slides, i conclude: Good presentation and he seems to like Apple Keynote,too.

Sometimes the standard behaviour of flushing the cache after writing the ZIL to disk hurts your performance more than nescessarry: For example when you have an storage array, that have an battery backed cache. The extra cache flush isn´t really nescessary to ensure data integrity, but hurts the performance on these system: Jason discusses this effect in an older blog entry: Shenanigans with ZFS flushing and intelligent arrays.... Nevertheless it´s an interesting read for everybody using ZFS on intelligent storage.