EON on a ZFS mirrored boot/root?

A typical operating system requires a boot disk and certain storage requirements to reside, boot and do what it's designed to do. The OS or boot disk where the operating system resides in a conventional install becomes a possible point of failure. The OS disk failing, would cause an outage and cut-off access to your data and storage appliance. RAID 1 or mirroring of the OS disk is often used to address/counter this type of failure. ZFS has the features to make an OS disk redundant by mirror-ing (RAID 1), providing an added layer of insurance to your storage appliance's uptime.

A design decision with EON, was to make it run from a RAM disk, hence it would not have an associated failure attached to the media(USB, CF or hard disk) it boots from or resides on. Size becomes a disadvantage running from a RAM disk but the trade off is an add layer of insurance, resilience and uptime. EON uses the boot/residence media mostly for out of band task that are not tied to performance and are not frequently used, so the typical 5+ MB/s performance of a USB/CF media is not a problem. After EON is booted, the USB media could be pulled (simulating a boot disk failure) and only the services below would be impacted. The important thing to note is that EON would continue to run, along with all the services enabled. The show goes on and facilitates dynamic repair or correction of the disk failure situation. EON uses the USB/CF media to preserve:

• edits to the configuration files
• edits to the grub menu entries or updating the image
• updates to the zpool.cache
• user optional binaries on the USB/CF media 

A ZFS boot/root was recently requested as a necessary feature/requirement for EON. I explained the resilience already built into the design and the challenges. I however gave it try the other night and succeeded in booting EON on a ZFS boot/root. This would allow the use of redundant USB/CF media. When will it be seen in a release? I'm not sure. It required using steps that were hard coded and needs more testing and refinement before it's ready for general audience and use. So yes, a ZFS boot/root for EON is possible. Here's a ZFS boot/root birth cry screenshot.

EON ZFS Storage 0.60.0 based on snv 130, Sun-set release!

Embedded Operating system/Networking (EON), RAM based live ZFS NAS appliance is released on Genunix! This release marks the end of SXCE releases and Sun Microsystems as we know it! It is dubbed the Sun-set release! Many thanks to Al at Genunix.org for download hosting and serving the Opensolaris community.

New to EON, start here! Upgrading, see how to use transporter.sh

EON Deduplication ZFS storage is available in 32 and 64-bit, CIFS and Samba versions:
EON 64-bit x86 CIFS ISO image version 0.60.0 based on snv_130

• eon-0.600-130-64-cifs.iso
• MD5: 55c5837985f282f9272f5275163f7d7b
• Size: ~93Mb
• Released: Monday 05-April-2010

EON 64-bit x86 Samba ISO image version 0.60.0 based on snv_130

• eon-0.600-130-64-smb.iso
• MD5: bf095f2187c29fb543285b72266c0295
• Size: ~106Mb
• Released: Monday 05-April-2010

EON 32-bit x86 CIFS ISO image version 0.60.0 based on snv_130

• eon-0.600-130-32-cifs.iso
• MD5: e2b312feefbfb14792c0d190e7ff69cf
• Size: ~59Mb
• Released: Monday 05-April-2010

EON 32-bit x86 Samba ISO image version 0.60.0 based on snv_130

• eon-0.600-130-32-smb.iso
• MD5: bcf6dc76bc9a22cff1431da20a5c56e2
• Size: ~73Mb
• Released: Monday 05-April-2010

EON 64-bit x86 CIFS ISO image version 0.60.0 based on snv_130 (NO HTTPD)

• eon-0.600-130-64-cifs-min.iso
• MD5: f5922c98888521e4d8bef10133ccbe40
• Size: ~87Mb
• Released: Monday 05-April-2010

EON 64-bit x86 Samba ISO image version 0.60.0 based on snv_130 (NO HTTPD)

• eon-0.600-130-64-smb-min.iso
• MD5: e74732c41e4b3a9a06f52779bc9f8352
• Size: ~101Mb
• Released: Monday 05-April-2010

New/Changes/Fixes:
- Active Directory integration problem resolved
- Hotplug errors at boot are being worked on and are safe to ignore.
- Updated /mnt/eon0/.exec with new service configuration additions (light, nginx, afpd, and more ...).
- Updated ZFS, NFS v3 performance tuning in /etc/system
- Added megasys driver.
- EON rebooting at grub(since snv_122) in ESXi, Fusion and various versions of VMware workstation. This is related to bug 6820576. Workaround, at grub press e and add on the end of the kernel line "-B disable-pcieb=true"

What's the best pool to build with 3 or 4 disks?

I've been asked many times in variations, "I just started using EON and I'm new to opensolaris, What's the best pool to build with 3 or 4 disks"? I usually answer, it depends! Credit that reflex answer to Prof. Gordon, one of the best Calculus and Differential equations teacher that walked in my time. May the force be with you, wherever you are!

I'll use Richard Elling's research to explain. Let's say I have 500Gb drives, with IOPs (for avg, small, random, cache-miss, read I/O operations per sec) = 70.59 and max media bandwidth of 133Mbytes/s(includes read and write). What can we build?

RAID Type   Disks   Sets   Storage Space   Performance (IOPS)   Max BW(Mbytes/s)
RAIDZ       4       1      3x500=1500Gb    4x70.59/3=94         3x133=399
RAIDZ       3       1      2x500=1000Gb    3x70.59/2=106        2x133=266 (1 spare)
STRIPE      4       1      4x500=2000Gb    4x70.59=282          4x133=532
STRIPE      3       1      3x500=1500Gb    3x70.59=212          3x133=399
MIRROR      2       2      2x500=1000Gb    4x70.59=282          4x133=532

RAIDZ
With 4 disks in the first raidz set, we get higher bandwidth (399Mbytes/s) vs the 3 disk raidz bandwidth (266Mbytes/s), but the 3 disk raidz pool has a higher I/O operations per second capability. Note, as "sets" are added to the 3 disk raidz (3 disks each time) the difference of IOPS between the 4 disk raidz widens. If you exhaust the usable storage space, it will cost 4 or 3 times the cost of a drive for each new "Set", to add or grow the storage. So the 3 drive raidz has a more economical cost per set. This can be repeated to add more "Sets" or more storage and bandwidth as needed. So this is a very flexible choice. The change with 1 additional set would look like.

RAID Type   Disks   Sets   Storage Space   Performance (IOPS)   Max BW(Mbytes/s)
RAIDZ       4       2      3000Gb          188                  798
RAIDZ       3       2      2000Gb          212                  532

Both 4 and 3 disk raidz allows only 1 disk to fail but if all disks had the same probability of failure then the 4 disk raidz pool would have a higher probability of a failure than the 3 disk version.

STRIPE
Has great bandwidth numbers, usable storage and IOPS, but any disk failure would cause the pool to fail and lose ALL your data. Did I mention that good storage is NOT a substitute for a GOOD backup? This pool is not easily expanded when the usable storage is exhausted and offers no data redundancy.

MIRROR
Has great bandwidth numbers, a higher cost per usable storage and allows failure of 2 disks. It has roughly twice the write bandwidth and up to 4 times the read performance as ZFS is capable of reading from all disks in the mirror in parallel. This configuration will most likely provide the best balance of performance and data protection at the expense of disks or usable storage. Expanding or growing this pool when the usable storage is being exhausted, is also simple.


Hopefully this will help architect pools that suits your workload, cost dynamics and growth needs.

Traffic (QoS) control built into your EON ZFS storage

Your EON ZFS storage provides access to a lot of services, such as HTTP, HTTPS, SFTP, Firefly/daapd, AFP(AppleShare) and more. All of these services are available as a network resource. Wouldn't it be nice to be able to control or manage how different systems use these network resources, such as bandwidth?

Project Crossbow provides the controls to manage and virtual-ize network resources. The traffic controls (QoS) can be used to manage by transport (TCP, UDP, SCTP, iSCSI, etc), bandwidth limits, IP address and more.

For example, one could simply limit the amount of bandwidth the HTTP, HTTPS or SSH service can utilize. You could create virtual nics bound to your real interface and provide different levels of service and bandwith to these virtual or real nics. It allows for a very flexible storage setup where you can really manage the traffic and quality of service it delivers.

Let's do a simple 10Mbps bandwidth limit for HTTP via interface bge0 for a flow we will label httpflow. First, we create a flow that matches the HTTP service

flowadm add-flow -l bge0 -a transport=tcp,local_port=80 httpflow

Let's view it

flowadm show-flow

Finally, let's set bandwidth limits

flowadm set-flowprop -p maxbw=10m httpflow

To verify the properties

flowadm show-flowprop

To show traffic usage

flowadm show-usage

Accounting can also be setup to record the usage. Rather than rehash the numerous possibilities, here are 2 links that details this feature fairly well. The first is written by Ben Rockwood and the other can be found here. Traffic control ... out!

Creating a EON ZFS storage self signed certificate

Your EON ZFS storage is available with 3 web server options, apache2(default), lighttpd, and nginx. They are provided with a self signed certificate that I created to simplify configuration and ease getting them started. The proper thing to do is replace it with your own certificate or create a self signed replacement.

Prerequisite(s): This requires the binary kit or an alternate system with a working openssl, to create your own self signed certificate.
The "\" means the command is one continuous line to create the self signed certificate. Feel free to experiment and substitute your own arguments for:
days = set to 365 x 10 = 3650 or ~10 yrs
CN = $HOSTNAME = replace with your own storage hostname
O = Gibraltar Engineering
OU = EON Secure Certificate

openssl req -x509 -nodes -days 3650 -newkey rsa:1024 -keyout cert.key -out cert.pem \
-subj "/C=US/ST=NY/CN=$HOSTNAME/O=Gibraltar Engineering/OU=EON Secure Certificate"

This will produce 2 files cert.key and cert.pem. For Apache2 they are configured and the proper permissions set as follows:

cp cert.pem /etc/apache2/2.2/server.crt
cp cert.key /etc/apache2/2.2/server.key
chmod 400 /etc/apache2/2.2/server.crt
chmod 400 /etc/apache2/2.2/server.key

For lighttpd the pem and key file are concatenated to create a single file

cp cert.pem /your_pool/lighttpd/etc
cat cert.key >> /your_pool/lighttpd/etc/cert.pem
chmod 400 /your_pool/lighttpd/etc/cert.pem

For nginx

cp cert.pem /your_pool/nginx/conf
cp cert.key /your_pool/nginx/conf
chmod 400 /your_pool/nginx/conf/cert.pem
chmod 400 /your_pool/nginx/conf/cert.key

The SUN has set, for the last time!

On January 27th at approximately 9:50am, Oracle completed it's acquisition of Sun Microsystems for 7.4 billion all cash. The price is quite a steal considering Sun's history of innovations. It is also personally quite sad to see one of the greatest engineering companies in my lifetime, like a beautiful descending Sun-set, descend beyond the horizon.

I was introduced to SunOS over 15 years ago when I had to take an electrical engineering class (Feedback Control Systems) that required running simulations on MatLab. They were the early days of the world wide web and the beginning of an engineering love/career. My internships, from there on were Sun and Solaris related. One beautiful summer, I went to The Herff College of Engineering in Memphis to learn and port a Cochlear model written in C by Dr. T Wilson, to Java. Without plans to do so, I made a career on something I learned and loved, as a sidebar tool. That tool was engineered by Sun Microsystems and for this I humbly say, THANKS for the great ride and memories, ... thanks to everyone who made Sun Microsystems what it became, is, was. It will be missed ...

EON ZFS Storage min and nginx web server

In a previous post, lighttpd was used as a add in web server for the EON ZFS min storage (NO HTTPD) users. Another web server option for the ZFS storage (NO HTTPD) image is nginx. This post will show how to easily add HTTPD service using the nginx web server. 

Prerequisite(s): A storage pool must be created and a binary kit must be installed. The binary kit is needed because it contains libpcre, a dynamic library needed by nginx.

Let's get started adding a nginx web server, to our ZFS min (NO HTTPD) storage image. First, get the pre-built nginx version 0.8.32 here. I have also included compilation notes under the nginx section in case you wish to compile and add other features on your own. Transfer the nginx-0,8.32,tgz file to the storage pool via CIFS share, sftp or USB. Here, I start with the file located in /tmp and a storage pool named abyss. Substitute your zpool name for abyss.

cd /abyss
gzip -dc /tmp/nginx-0.8.32.tgz | tar -xf -

Now let's add the automation entries to /mnt/eon0/.exec. Also, execute the commands to create the necessary symlinks. These entries align paths entered in nginx.conf

(cd /usr ; ln -s ../abyss/nginx .)

At this stage, the nginx web server is ready to run, but feel free to customize the /abyss/nginx/conf/nginx.conf and generate your own /abyss/nginx/conf/cert.pem, /abyss/nginx/conf/cert.key file. OpenSSL (part of the binary kit which is a pre-requisite for this post) would be needed to generate your own self signed cert file (cert.pem, cert.key). To start and automate the web server, run and add the following to /mnt/eon0/.exec.

/usr/nginx/sbin/nginx -c /usr/nginx/conf/nginx.conf

EON ZFS Storage min and lighttpd web server

If you run one of the EON ZFS (NO HTTPD) storage images that do not include a web server this post will show how to easily add HTTPD service using the lighttpd or nginx web server. 

Prerequisite(s): A storage pool must be created and a binary kit must be installed. The binary kit is needed because it contains libpcre, a dynamic library needed by lighttpd.

Let's get started adding a lighttpd web server, to our ZFS min (NO HTTPD) storage image. First, get the pre-built lighttpd version 1.4.25 here. I have also included compilation notes under the lighttpd section in case you wish to compile and add other features on your own. Transfer the lighttpd-1.4.25.tgz file to the storage pool via CIFS share, sftp or USB. Here, I start with the file located in /tmp and a storage pool named abyss. Substitute your zpool name for abyss.

cd /abyss
gzip -dc /tmp/lighttpd-1.4.25.tgz | tar -xf -

Now let's add the automation entries to /mnt/eon0/.exec. Also, execute the commands to create the necessary symlinks. These entries align paths entered in lighttpd.conf

(cd /usr ; ln -s ../abyss/lighttpd .)
(cd /var ; ln -s ../abyss/lighttpd .)

At this stage, the lighttpd web server is ready to run, but feel free to customize the /abyss/lighttpd/etc/lighttpd.conf and generate your own /abyss/lighttpd/etc/server.pem file. OpenSSL (part of the binary kit which is a pre-requisite for this post) would be needed to generate your own self signed cert file (server.pem). To start and automate the web server, run and add the following to /mnt/eon0/.exec.

/usr/lighttpd/sbin/lighttpd -f /usr/lighttpd/etc/lighttpd.conf

EON ZFS Storage 0.59.9 based on snv 129, Deduplication release!

Embedded Operating system/Networking (EON), RAM based live ZFS NAS appliance is released on Genunix! This is the first EON release with inline Deduplication features! Many thanks to Genunix.org for download hosting and serving the opensolaris community.

EON Deduplication ZFS storage is available in 32 and 64-bit, CIFS and Samba versions:
EON 64-bit x86 CIFS ISO image version 0.59.9 based on snv_129

• eon-0.599-129-64-cifs.iso
• MD5: 8e917a14dbf0c793ad2958bdf8feb24a
• Size: ~93Mb
• Released: Monday 21-December-2009

EON 64-bit x86 Samba ISO image version 0.59.9 based on snv_129

• eon-0.599-129-64-smb.iso
• MD5: 2c38a93036e4367e5cdf8a74605fcbaf
• Size: ~107Mb
• Released: Monday 21-December-2009

EON 32-bit x86 CIFS ISO image version 0.59.9 based on snv_129

• eon-0.599-129-32-cifs.iso
• MD5: 0dcdd754b937f1d6515eba34b6ed2607
• Size: ~59Mb
• Released: Monday 21-December-2009

EON 32-bit x86 Samba ISO image version 0.59.9 based on snv_129

• eon-0.599-129-32-smb.iso
• MD5: c24008516eb4584a64d9239015559ba4
• Size: ~73Mb
• Released: Monday 21-December-2009

EON 64-bit x86 CIFS ISO image version 0.59.9 based on snv_129 (NO HTTPD)

• eon-0.599-129-64-cifs-min.iso
• MD5: 78b0bb116c0e32a48c473ce1b94e604f
• Size: ~87Mb
• Released: Monday 21-December-2009

EON 64-bit x86 Samba ISO image version 0.59.9 based on snv_129 (NO HTTPD)

• eon-0.599-129-64-smb-min.iso
• MD5: 57d93eba9286c4bcc4c00c0154c684de
• Size: ~101Mb
• Released: Monday 21-December-2009

New/Changes/Fixes:
- Deduplication, Deduplication, Deduplication. (That only used 1x the amount of storage space)
- The hotplug errors at boot are being worked on. They are safe to ignore.
- Cleaned up minor entries in /mnt/eon0/.exec. Added "rsync --daemon" to start by default.
- EON rebooting at grub(since snv_122) in ESXi, Fusion and various versions of VMware workstation. This is related to bug 6820576. Workaround, at grub press e and add on the end of the kernel line "-B disable-pcieb=true"

EON ZFS Storage 0.59.5 based on snv 125 released!

Embedded Operating system/Networking (EON), RAM based live ZFS NAS appliance is released on Genunix! Many thanks to Al Hopper and Genunix.org for download hosting and serving the opensolaris community.

EON ZFS storage is available in 32 and 64-bit, CIFS and Samba versions:
EON 64-bit x86 CIFS ISO image version 0.59.5 based on snv_125

• eon-0.595-125-64-cifs.iso
• MD5: a21c0b6111803f95c29e421af96ee016
• Size: ~90Mb
• Released: Thursday 3-December-2009

EON 64-bit x86 Samba ISO image version 0.59.5 based on snv_125

• eon-0.595-125-64-smb.iso
• MD5: 4678298f0152439867d218987c3ec20e
• Size: ~103Mb
• Released: Thursday 3-December-2009

EON 32-bit x86 CIFS ISO image version 0.59.5 based on snv_125

• eon-0.595-125-32-cifs.iso
• MD5: 4b76893c3363d46fad34bf7d0c23548c
• Size: ~57Mb
• Released: Thursday 3-December-2009

EON 32-bit x86 Samba ISO image version 0.59.5 based on snv_125

• eon-0.595-125-32-smb.iso
• MD5: f478a8ea9228f16dc1bd93adae03d200
• Size: ~70Mb
• Released: Thursday 3-December-2009

EON 64-bit x86 CIFS ISO image version 0.59.5 based on snv_125 (NO HTTPD)

• eon-0.595-125-64-cifs-min.iso
• MD5: c7b9ec5c487302c1aa97363eb440fe00
• Size: ~85Mb
• Released: Thursday 3-December-2009

EON 64-bit x86 Samba ISO image version 0.59.5 based on snv_125 (NO HTTPD)

• eon-0.595-125-64-smb-min.iso
• MD5: a33f34506f05070ffc554de7beaafd4d
• Size: ~98Mb
• Released: Thursday 3-December-2009

New/Changes/Fixes:
- removed iscsitgd and replaced it with COMSTAR (iscsit, stmf, itadm)
- added SUNWhd to image vs being in the binary kit.
- added rsync to image vs being in the binary kit. Updated version of rsync supports IPv6.
- added nge, yge and yukonx drivers.
- added (/etc/inet/hosts, /etc/default/init) to /mnt/eon0/.backup (TIMEZONE and hostname change fix)
- fixed error entry /mnt/eon0/.exec. Changed "zpool -a" to "zpool import -a"
- eon rebooting at grub(since snv_122) in ESXi, Fusion and various versions of VMware workstation. This is related to bug 6820576. Workaround, at grub press e and add on the end of the kernel line "-B disable-pcieb=true"

Using napp-it webadmin with your EON ZFS storage

Many have asked for a web interface to administer their EON ZFS storage. I started a FreeNAS interface port a while back but time and keeping pace with their development proved unsustainable. I shared it in the download section as Freon for someone with better PHP resources to complete. I also posted a webmin howto a while back. The webmin web user admin, lacks only a ZFS and a CIFS module. It contains a Samba module which may be easy for one of you Perl guru's out there to extend as a CIFS module.

Prerequisites: This exercise assumes the binary kit is installed, for unzip. Or unzip with winzip and drag the folder into a CIFS share onto the storage, then run the following within the napp-it directory to correct the proper unix carriage return:

find . -type f -print | xargs -I {} dos2unix -ascii {} {}

Another option, written by Alka Guenther for nexenta, called napp-it was extended to work with EON. He has a running thread on opensolaris.org. Here are the steps I took to get it running on my ZFS storage after downloading napp-it v 0.210. I transferred it to /tmp/napp-it-0.210.zip. Then

cd /var/apache2/2.2/cgi-bin
unzip -aa /tmp/napp-it-0.210.zip
chown webservd:webservd napp-it
cd napp-it
chmod -R 755 ./*

Next we vi/edit admin.pl and comment (line 42 in v 0.210) the following

use CGI::Carp qw (fatalsToBrowser);

to

#use CGI::Carp qw (fatalsToBrowser);

And that's pretty much it. We point the browser to http://EON_ZFS_IP/cgi-bin/napp-it/admin.pl and you should be greeted by a login with no password, which you can immediately change. It is very configurable and I really liked the console command feature. So give it a try and help improve it.

How is EON ZFS storage working for you?

For release 0.59.5 based on snv_125 I am thinking of adding 2 more images. A 64-bit CIFS and Samba version without any embedded web server. These images would be able add a web server based on lighttpd, if needed. I'd like to hear your thoughts on this? With the great news that ZFS de-duplication is complete, we can hope to see a SXCE release. Many thanks to Jeff Bonwick, Bill Moore, Mark Maybee, Matt Ahrens, Adam Leventhal, George Wilson, Robin Guo and all the engineers who made this happen.

I would also appreciate your feedback/review in format(pros:, cons:, and other thoughts:), to understand how EON ZFS storage is filling/failing your storage needs, thus far. I may not be able to address all needs but it would be great to understand how EON is working with you, whether it's good, bad or indifferent.

Update for future releases based on feedback:
- shift SUNWhd, S.M.A.R.T and rsync to the core image, instead of the binary kit.
- attempt to add more intel, broadcom nic drivers. (Note: not all drivers can be added because of image size contribution. Also I have no way of testing with certain hardware. There is a mechanism to add your own drivers)
- add 2 new 64-bit CIFS and Samba versions, with NO HTTP service. Will rely on external lighttpd, if HTTP service is needed.
- add COMSTAR, to replace iscsitgtd.
- documentation to help new to opensolaris, beginners and less technical audience. It would help greatly if you, the user would document or do write-ups, based on your experiences and challenges with EON. I could add the write-up to the wiki to help others. Proper credit will be given for your work.

EON ZFS Storage 0.59.4 based on snv_124 released!

Embedded Operating system/Networking (EON), RAM based live ZFS NAS appliance is released on Genunix! Many thanks to Genunix.org for download hosting and serving the opensolaris community.

EON ZFS storage is available in 32 and 64-bit, CIFS and Samba versions:
EON 64-bit x86 CIFS ISO image version 0.59.4 based on snv_124

• eon-0.594-124-64-cifs.iso
• MD5: 4bda930d1abc08666bf2f576b5dd006c
• Size: ~89Mb
• Released: Monday 19-October-2009

EON 64-bit x86 Samba ISO image version 0.59.4 based on snv_124

• eon-0.594-124-64-smb.iso
• MD5: 80af8b288194377f13706572f7b174b3
• Size: ~102Mb
• Released: Monday 19-October-2009

EON 32-bit x86 CIFS ISO image version 0.59.4 based on snv_124

• eon-0.594-124-32-cifs.iso
• MD5: dcc6f8cb35719950a6d4320aa5925d22
• Size: ~56Mb
• Released: Monday 19-October-2009

EON 32-bit x86 Samba ISO image version 0.59.4 based on snv_124

• eon-0.594-124-32-smb.iso
• MD5: 3d6debd4595c1beb7ebbb68ca30b7391
• Size: ~69Mb
• Released: Monday 19-October-2009

New/Changes/Fixes:
- initialization of ntpd, nscd at boot time, moved to /mnt/eon0/.exec
- added /mnt/eon0/.disable for K99local stop for a cleaner shutdown
- added /mnt/eon0/.purge to allow removing drivers and binaries not needed by your image
- new version of install.sh. Fixes a bug for virtual disks, multiple runs and improved error checking of stages
- new transporter.sh CLI to automate upgrades, backups or downgrades to backed-up versions
- eon rebooting at grub(since snv_122) in ESXi, Fusion and various versions of VMware workstation. This is related to bug 6820576. Workaround, at grub press e and add on the end of the kernel line "-B disable-pcieb=true"

A new and simpler way to upgrade EON ZFS storage

There is a new and simple way to upgrade your current EON ZFS storage to the newest version. I've added a tool, transporter.sh which allows you to backup, upgrade or restore(NOTE: restore only works if you have a backed-up version) your EON ZFS storage version. Here is a usage output:

transporter.sh 
usage: transporter.sh -i /path/eon.iso -b /path/backup -d /mnt/eon0
transporter.sh -i /tmp/eon-0.593-122-64-smb.iso -d /mnt/eon0
transporter.sh -i /tmp/eon-0.593-122-64-smb.iso -b /pool/backup -d /mnt/eon0
transporter.sh -r /pool/backup/0.59.3 -d /mnt/eon0

-i path to the source ISO
-b path to the backup destination [optional]
-d path to the upgrade destination
-r path to the restore source [optional]

Here's an example run without backup options. It is always wise to have a backup. I cannot stress this enough. There is no backup in this example because I have a previous backup in /abyss/eonback/0.593.

transporter.sh -i /tmp/eon.iso -d /mnt/eon0
OK: lofiadm -a /tmp/eon.iso /dev/lofi/1
OK: mount -F hsfs /dev/lofi/1 /tmp/upgrade
removing /mnt/eon0/boot
copying /tmp/upgrade -> /mnt/eon0
x ., 0 bytes, 0 tape blocks
x ./boot, 0 bytes, 0 tape blocks
x ./boot/amd64, 0 bytes, 0 tape blocks
x ./boot/grub, 0 bytes, 0 tape blocks
x ./boot/grub/bin, 0 bytes, 0 tape blocks
x ./boot/grub/bin/grub, 180380 bytes, 353 tape blocks
[...]   excerpt clipped
./boot/platform/i86xpv/kernel/amd64, 0 bytes, 0 tape blocks
x ./boot/platform/i86xpv/kernel/amd64/unix, 2084984 bytes, 4073 tape blocks
x ./boot/platform/i86xpv/kernel/unix, 1544152 bytes, 3016 tape blocks
x ./boot/x86.eon, 49523134 bytes, 96725 tape blocks
x ./.backup, 1454 bytes, 3 tape blocks
x ./.catalog, 2048 bytes, 4 tape blocks
x ./.disable, 137 bytes, 1 tape blocks
x ./.exec, 1383 bytes, 3 tape blocks
x ./.remove, 3264 bytes, 7 tape blocks
unmounting /dev/lofi/1
OK: umount /dev/lofi/1
releasing /dev/lofi/1
OK: lofiadm -d /dev/lofi/1

Please report any inconsistent findings.

Thumper features in EON ZFS storage

With binary kit 122, the package SUNWhd (tools and driver download) used in thumper was added to EON. With this package you get the capability to tell a great deal of metrics about your disks. It gives the ability to control read and write cache. It allows to tell firmware revision, vendor, serial and very importantly, the temperature of the disks.

We know that higher temperature disks, perform less efficiently. In my DIY ZFS storage case, hdadm showed that there was insufficient cooling or air was not being moved efficiently through the cage as the temperature of the 15K rpm drives continuously inched towards the clip or shutdown temperature. The clip temperature can be seen in the output of:

smartctl -d scsi -a /dev/rdsk/cXtXdXsX
...   excerpt
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK

Current Drive Temperature:     48 C
Drive Trip Temperature:        65 C
Manufactured in week 31 of year 2006

Re-orientation of the drives and re-positioning a 20MM fan seems to be holding at 53 degree C. I'll focus on getting temperatures down to the 36-40 degree C range. For more use see hdadm which is a wrapper script for calling the hd binary.

hdadm display
                                                            
Device    Serial        Vendor   Model             Rev  Temperature
------    ------        ------   -----             ---- -----------
c0t1d0p0  DNL3P68018NM  FUJITSU  MAX3036NC         5D03 53 C (127 F)
c0t2d0p0  DNL3P6400SDR  FUJITSU  MAX3036NC         5D03 58 C (136 F)
c0t3d0p0  DNL3P68018NN  FUJITSU  MAX3036NC         5D03 54 C (129 F)
c1t1d0p0  DNL3P6400SEE  FUJITSU  MAX3036NC         5D03 49 C (120 F)
c1t2d0p0  DNL3P68018BC  FUJITSU  MAX3036NC         5D03 51 C (123 F)
c1t3d0p0  DNL3P68018NV  FUJITSU  MAX3036NC         5D03 46 C (114 F)
c2d0p0    HNCF128MMG=STCB21M84025C03356C1  MG      84025C03356C1     -    None

A hard drive performance test can be run using:

hdadm diskqual