c0t0d0s0.org

The next release of Solaris 10 is imminent. As the Sun website states: Solaris 10 5/08 will be available for download on 4/16/08. So it may be interesting to you, what new features found their way in 5/08. Well, you can already look into the What's New in the Solaris 10 5/08 Release document.

• System Resource Enhancements
• CPU Caps
• projmod(1M) Option


• Device Management Enhancements
• Tape Self-Identification
• x86: Enhanced Speedstep CPU Power Management
• iSNS Support in the Solaris iSCSI Target


• Security Enhancements
• Solaris Trusted Extensions Supports Mounting Labeled File Systems With the NFSv3 Protocol
• SPARC: Hardware -Accelerated Elliptical Curve Cryptography (ECC) Support


• Networking Enhancements
• Sockets Direct Protocol
• Tunable inetd Backlog Queue Size


• X11 Windowing Enhancements
• Xvnc Server and Vncviewer Client


• System Administration Enhancements
• Solaris Trusted Extensions Administrator Procedures
• Flash Update Tool
• PPD File Management Utility
• Internet Printing Protocol Client-Side Support
• Selectable Use of localhost for Solaris Print Server Database Hostname
• Fault Management for T5140/T5240 Platforms
• SunVTS 7.0


• Desktop Tools Enhancements
• new version StarOffice 8
• Flash Player 9
• Pidgin 2.0
• PAPI Print Commands


• System Performance Enhancements
• 64-bit SPARC: Memory Placement Optimization Support for sun4v Platforms
• SPARC: Shared Contexts Support
• x86: CPUID-Based Cache Hierarchy Awareness


• Language Support Enhancements
• Locale Creator
• libchewing 0.3.0
• File Encoding Examiner


• Kernel Functions Enhancements
• x86: MONITOR and MWAIT CPU Idle Loop


• Driver Enhancements
• x86: Support Sun Fire X4540 Disk Status Indicators
• MPxIO Extension for Serial Attached SCSI Devices on mpt(7D)
• x86: SATA ATAPI Support in AHCI Driver
• x86: GLDv3 Version bnx II Driver
• x86: AMD–8111
• SATA NCQ Support in AHCI Driver
• x86: bnx II Ethernet Driver
• USB-to-Serial Driver for Keyspan Adapters


• Freeware Enhancements
• 32-bit: pgAdmin III
• p7zip

Pheewww ... i´ve finalized my SamFS tutorial, a long text. SamFS is the hierarchical Storage Management Filesystem from sun. Several new concepts, so you have to explain some theory before getting to the shell:

• Part 1: Introduction.html
• Part 2: The theory of Hierarchical Storage Management
• Part 3: The Jargon of SamFS
• Part 4: Installation of the packages
• Part 5: Configuring a SamFS filesystem
• Part 6: Configuring disk archiving
• Part 7: Working with SamFS
• Part 8: Usecases and future directions
• Part 9: Conclusion

As usual: Have fun!

Now we´ve configured a file system and we set up the archiver for it. Now let´s use it.

Okay, now we can configure our first filesystem with SamFS.

It´s quite easy to install SamFS. It´s just installing two packages and answering some questions.

As usual, this technology has it´s own jargon. Thus i will start to define the most important words at first.

I think, i should start with the theory of Hierarchical Storage Management(HSM). The technology of managing data and their position on different media isn´t really a widespread feature for most adminstrators. Thus this introduction will be a quite long one.

Okay, this is tutorial isn´t really about feature of Solaris itself. But the feature of this tutorial it´s deeply coupled with Solaris. Thus you can view it as an optional part of Solaris. This time i will dig into the installation and configuration of SamFS. But a warning, SamFS is a feature monster. This tutorial is equivalent to put your toes in the Atlantic ocean, but when i saw the annoucement of the open-sourcing of SamFS i thought, it´s time to write this document. In addition to that, it was a nice way to make a reality check on a thought game, i´ve made some months ago.

I wrote about iSCSI quite often in the last time. But how can you use it in Solaris. I wrote a short introduction about the usage of the iSCSI implementation of Solaris:

• Part 1: Introduction
• Part 2: Basic iSCSI
• Part 3: Bidirectional authenticated iSCSI
• Part 4: Alternative backing store
• Part 5: Conclusion

And as usual: Have fun while trying iSCSI on Solaris!

Okay, this was a quick introduction to the actual implementation of iSCSI on Solaris. The future will bring changes to the implementation of the iSCSI target feature but new possibilities as well. iSCSI will be an part of the COMSTAR framework in the future besides of an SAS target or an FC target.

Albeit it´s very easy to use iSCSI in conjunction with ZFS emulated volumes it doesn´t have to be this way. You can use different kinds of backing store for iSCSI

Okay, but we are in a public network. How can we protect the target against a user not allowed to use it? iSCSI supports a CHAP based authentication. It´s the same scheme as with PPP. With this authentication, target and initiator can authenticate each other based on shared secrets. The configuration is a little bit more complex, as both initiator and target have to know the secrets and their names of each other.

At first I will show you, how to do a really simple iSCSI configuration. This is without any authentication. Thus everybody can connect to the iSCSI targets on the system. But this is sufficient for a test. And it´s this is better for having a quick success.

With more and more available bandwidth it gets more and more feasible to use only a single network to transmit data in the datacenter. Networking can get really complex when you have to implement two networks. For example for Ethernet and one for FC. It´s getting more complex and expensive, as FC network are mostly optical ones and Ethernet is a copper network in most datacenters.

I had an idea to vastly reduce the network load for iSCSI harddisks while waiting for the water to boil for my first tea. There are two new features in development for ZFS: L2ARC and Separated ZIL. L2ARC enables ZFS to use a disc as a second level cache (thus speeding up reads). The Separated ZIL enables ZFS to use a disc as to use a dedicated disc for the ZFS Intent Log (thus speeding up writes). Both features were designed with solid state disks in mind to augment "rotating rust" hard disks. But this features are not limited to this high end task.

Think about the following usecase: A server has in most cases some local boot disks even when you use iSCSI or FC. From a 146 GB disc you need only roundabout 20 GB (2x 7.5 for OS incl. Live Upgrade Partition and 5 GB for swap) or so. Thus you have 126 GB left. Okay, let´s assume, that you have two X4500 exporting zvols with iSCSI.

You have another machine in your network. You create an mirrored ZFS pool out of the remote iSCSI volume. But now the both new features come into the game. We augment this iSCSI volume with a local separated ZIL and a local L2ARC. With the first one, you keep the log writes from the network and with the local L2ARC you get an really huge local cache without sacrifying precious memory resources. Many read/write requests stay local to the system and you can vastly reduce the load to the network. Thus you are capable to put even more I/O intensive tasks on this system.