FUSE in Solaris 11

It looks like the final version of Solaris 11 will get FUSE (PSARC 2010/456). It was previously under development for OpenSolaris but never integrated and the project has not been updated for at least year. It now seems like Oracle internally have resumed the FUSE development for Solaris 11 and plans to integrate it into the internal snv_163 build which opens in about a month.

"The FUSE project (PSARC/2010/456) introduces the UVFS file system so we need a uvfs.7fs to briefly describe this feature. Content will be provided by the
FUSE team.

Projected Nevada integration build is snv_163."

OpenSolaris FUSE project

Zones should be able to be NFS servers

NFS service in local zones have been frequently requested since the introduction of zones in Solaris 10, the change request for this even predates Solaris 10 by two years, it was filled in 2003. I've earlier mentioned that some works was being done to this including PSARC/2010/208. Now it seems that this has been implemented and will be integrated into internal build 154 of Solaris Next. This is hopefully in time for the first release of Solaris 11 Express which is expected next month.

Update: I was a bit quick on this one, build 154 should close in the end of next month, that does not work very well with a November release of Solaris Express, so it might be delayed or more probably it will not be part of the first Express release.

Zones should be able to be NFS servers, bugid 4964859
NFS Instances with NFS shares.
PSARC/2010/208

zonestat implemented

We are not left out in the dark yet, the gates are still open and we can see changes made to the OpenSolaris source, the source that is going to be used for Solaris 11.

Today PSARC/2010/29 zonestat was implemented, it provides enhanced observability for Solaris zones. prstat -Z can provide a nice overview of all zones on a system but it does not tell you anything about any resource capping of memory or CPU resources. There have been a perl-script with the same name available for some time which is able to extract and present a nice summary of zones and their capping and usage. This is not only a reimplementation in C, it is also architectures the new observability feature into three layers, a collection daemon, an API and a command line utility. This case has requested patch binding and it should not be hard or include any significant risk to backport it to a Solaris 10 update.

Examples from the PSARC:

Example 1: Summary of cpu and memory usage over a 5 second interval:
    # zonestat 5 1
    SUMMARY
                -----CPU------------- ----PHYSICAL--- ----VIRTUAL----
           ZONE USED %PART %CAP %SHRU USED  PCT  %CAP  USED  PCT %CAP
        [total] 9.74   30%    -     - 7576M  23%    - 11.6G  24%    -
       [system] 0.28  0.8%    -     - 6535M  19%    - 10.4G  21%    -
         global 9.10   28%    -     -  272M 0.8%    -  366M 0.7%    -
      kodiak-ab 0.32  1.0%    -     -  256M 0.7%    -  265M 0.5%    -
      kodiak-dp 0.00  0.0%    -     - 77.6M 0.2%    - 71.1M 0.1%    -
kodiak-gjelinek 0.00  0.0%    -     - 58.7M 0.1%    - 59.3M 0.1%    -
     kodiak-edp 0.00  0.0%    -     - 53.0M 0.1%    - 58.9M 0.1%    -
 kodiak-johnlev 0.00  0.0%    -     - 51.9M 0.1%    - 57.4M 0.1%    -
  kodiak-jordan 0.00  0.0%    -     - 51.7M 0.1%    - 56.8M 0.1%    -
   kodiak-steve 0.00  0.0%    -     - 51.5M 0.1%    - 56.2M 0.1%    -
   kodiak-susan 0.00  0.0%    -     - 48.9M 0.1%    - 55.7M 0.1%    -
kodiak-batschul 0.00  0.0%    -     - 48.5M 0.1%    - 49.5M 0.1%    -
 kodiak-garypen 0.00  0.0%    -     - 46.3M 0.1%    - 49.5M 0.1%    -
     kodiak-rie 0.00  0.0%    -     - 22.7M 0.0%    - 49.4M 0.1%    -

PSARC/2010/291 zonestat

Read-only zpools implemented

Read-only zpools have now been implemented in the source as proposed in PSARC/2010/306.

Previously individual filesystem have could be mounted as read-only, but now the whole pool can be imported this way:
# zool import -o readonly=on zpool01

When importing a pool with read-only, no writes will be performed to any of the devices in the pool, they are even opened read-only.

From the PSARC:
"When the 'readonly' property is 'on' (read-only) the following actions are performed:

1). pool is loaded but transaction processing is disabled
2). all filesystems and zvols are mounted in read-only mode
3). any intent-log replays are deferred (any pending synchronous
writes will be replayed once the pool is imported read-write)

The following restrictions apply when a pool is read-only:

1). Attempts to set additional zpool-level properties during import
are ignored.
2). All filesystem mounts are converted to include the 'ro'
mount option.
3). Additional mount options may be set on a temporary basis.

A pool which has been imported read-only can be restored back to read-write by exporting and reimporting it."

PSARC/2010/306 Read-only ZFS pools

ZFS diff

A really nice feature have been implemented for ZFS, which allows you to list all file changes between two snapshots of a ZFS filesystem. The PSARC was filled in March but it has now been implemented. It will have a simple syntax just like diff(1):
# zfs diff zpool01/fs01@snap01 zpool01/fs02@snap02

With output in this format:

M       /myfiles/
M       /myfiles/link_to_me   (+1)
R       /myfiles/rename_me -> /myfiles/renamed
-       /myfiles/delete_me
+       /myfiles/new_file

From the PSARC:
" There is a long-standing RFE for zfs to be able to describe
what has changed between the snapshots of a dataset.
To provide this capability, we propose a new 'zfs diff'
sub-command. When run with appropriate privilege the
sub-command describes what file system level changes have
occurred between the requested snapshots. A diff between the
current version of the file system and one of its snapshots is
also supported.

Five types of change are described:

o File/Directory modified
o File/Directory present in older snapshot but not newer
o File/Directory present in newer snapshot but not older
o File/Directory renamed
o File link count changed

PSARC/2010/105 zfs diff

Notification enhancements

A common request from smaller shops or private users of Solaris is that they want email notifications when something is wrong with their system. This is most common with ZFS filers, they might not have any surveillance systems implemented but want to be sure to get a notification if something goes wrong with a zpool. A quick fix to this is of course a small script which can dump zpool or FMA errors over email but it is not a standardized or complete solution.

Now there have been a large putback in OpenSolaris that among other things delivers this functionality. FMA faults and SMF events can with these change be configured to deliver notifications over mail or SNMP. It also enables the fault management daemon in local zones so that they can deliver SMF state changes from within the zone. Using this framework you can also configure any of your own SMF services to deliver state change notification over any of these two protocols.

PSARC/2009/617 Software Events Notification Parameters CLI
PSARC/2009/618 snmp-notify: SNMP Notification Daemon for Software Events
PSARC/2009/619 smtp-notify: Email Notification Daemon for Software Events
PSARC/2010/225 fmd for non-global Solaris zones

New ZFS recovery option

Currently if you loose a non-redundant log device in your zpool it becomes impossible to import, there is no way to exclude the log device and import the rest of the pool. There are however light on the horizon, PSARC 2010/292 proposes a solution to this problem with a new switch for the zpool import command.

From the PSARC:
"This fast-track introduce a new command line flag to the
'zpool import' sub-command. This new option, '-m', allows
pools to import even when a log device is missing. The contents
of that log device are obviously discarded and the pool will
operate as if the log device were offlined."

PSARC 2010/292 zpool import despite missing log

Update
This has now been implemented in the source, the changeset is here.