Skip to content

Forced to upgrade

November 22, 2008

Build 103 and ZFS root have come to the home server. While I was travelling the system hit bug 6746456 which resulted in the system panicing every time it booted. So I was forced to return to build 100 and have now upgraded to build 103. Live upgrade using UFS would not work at all and since I have the space I’ve moved over to ZFS root. However the nautilus bug is still in build 103 so I’m either going to have to live with it, which is impossible, disable nautilus completely or work to get the time slider feature disabled until it is usable. Disabling nautilus while irritating is effectively what I have had to do now so could be the medium term solution.

The other news for the home server was the failure of the power supply. So it was good bye to the small Antec case that used to house the server since it did not really save any space a more traditional desk side unit has replaced it which also allows upto six internal drives. Since ZFS root will not support booting of stripes the extra two drives I have form a second pool.

# zpool list NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT pool2   294G  36.8G   257G    12%  ONLINE  – tank    556G   307G   249G    55%  ONLINE  – #  

The immediate effect of two pools is being able to have the Solaris image from which I upgraded on a different pair of disks from the ones being upgraded with a dramatic performance boost. The other is that I can let the automatic snapshot service take control of the other pool rather than add it to my old snapshot policy. Early on I realise I need to turn off snapshots on the swap volumes which are on both pools (to get some striping):

# zfs set com.sun:auto-snapshot=false pool2/swap #  zfs set com.sun:auto-snapshot=false tank/swap  #  

should do it.

Advertisements

From → Solaris

One Comment
  1. Yep – the swap/dump problem was fixed by
    6762213 We should not snapshot swap or dump devices by default
    and then again by:
    http://defect.opensolaris.org/bz/show_bug.cgi?id=4644
    (as time-slider neatly side-stepped the original
    fix! Gory details in the url above)
    We should be doing the right thing for swap
    and dump at this stage – the only edge-case now
    being swap zvols that are added while the service
    is already started will still get snapshotted.
    (The somewhat heavy-handed fix
    for 4644 will ensure those swap vols are excluded
    next time the service starts)
    I’m not sure when the latter fix will get
    integrated into SXCE, but it’s in the project gate
    already.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: