I don’t do a lot of Solaris anymore, and though I’m interested in several of the new features in the upcoming Solaris 11, I wasn’t aware until today that it wouldn’t run on most legacy UltraSPARC systems:
Support for legacy systems that have included the UltraSPARC I, II, IIe, III, IIIi, III+, IV and IV+ processor architectures (as reported by the Solaris ‘psrinfo -pv’ command) has been removed. All Oracle SPARC Enterprise M-Series Servers and Oracle SPARC T-Series Servers will continue to be supported.
I’ve always liked the T-Series systems, and have personally achieved what I consider impressive workload consolidation using a few of them. It’s not entirely clear what Oracle means with the above statement, but rumor is that support for the sun4u architecture is gone. That’s a big change from the Solaris 11 Express HCL. I imagine there are lots of places where this means “we will never ever run Solaris 11.”
Reminds me of a certain fruit company. Time marches on.
Despite what you might read at docs.sun.com, Solaris 10 update 6 doesn’t have a “-u” option for `zfs receive`.
jmcmurry@lemon $ cat /etc/release
Solaris 10 10/08 s10s_u6wos_07b SPARC
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 27 October 2008
jmcmurry@lemon $ zfs receive -u
invalid option 'u'
This could’ve been brought to my attention before I decide to create my ZFS export streams recursively. One at a time, I’d have been fine. What seemed to be an awesome way to retrofit a metadata slice for an SVM volume into a whole disk ZFS root install turned out to be a miserable trail of heartache and pain.
But I can take it; I am a Unix guy.
UPDATE: “-u” seems to be in Solaris 10 update 7, but even there, it’s not in the man page for zfs(1M). Thanks so much for updating the docs without indicating that the “recover your root storage” function only works on the OS release that you made available for download today.
Today I wanted to move a Solaris 9 zone running on a Solaris 10 test server to a new ZFS dataset within the same ZFS pool with compression enabled. This container is an archive of an environment we don’t use very much, normally leave shut down, and intend to delete fairly soon, but since it’s a flash archive of a Solaris 9 machine, it takes up a lot of space on the test system’s local disks.
First I created the new dataset:
# zfs create rpool/zones
# zfs set mountpoint=/zones rpool/zones
# zfs create rpool/zones/foo
# zfs set compression=on rpool/zones/foo
I thought I should halt the zone, update the zonepath property for the zone, move the files to the new place, and start up the zone. Nope:
zonecfg:foo> set zonepath=/zones/foo
Zone foo already installed; set zonepath not allowed.
Great, now I’m going to have to search through a bunch of docs and maybe remove the zone and redo it all and why can’t they make this easy for me, argh.
Well, they did:
# zoneadm -z foo move /zones/foo
I like a lot of the changes in Solaris 10, especially the usage and man pages for things like zfs(1M). These commands tend to do the annoying things for you and the man pages have lots of examples. Nice.
# zfs get compressratio rpool/zones/foo
NAME PROPERTY VALUE SOURCE
rpool/zones/foo compressratio 1.44x -