K 10
svn:author
V 7
delphij
K 8
svn:date
V 27
2013-07-05T04:02:15.182503Z
K 7
svn:log
V 4116
MFC r251636: illumos #3749 zfs event processing should work on R/O root
filesystems

This log is a modified version of the original one written by gibbs@,
to account for changes made during the illumos RTI process.

Allow ZFS asynchronous event handling to proceed even if the root file
system is mounted read-only.  This restriction appears to have been put
in place to avoid errors with updating the configuration cache file.
However:

 o The majority of asynchronous event handling does not involve
   configuration cache file updates.
 o The configuration cache file need not be on the root file system,
   so the check was not complete.
 o Other classes of errors (e.g. file system full) can also prevent
   a successful update yet do not prevent asynchronous event processing.
 o Configurations such as NanoBSD never have a read-write root,
   so ZFS event processing is permanently disabled in these systems.
 o Failure to handle asynchronous events promptly can extend the
   window of time that a pool is in a critical state.

At worst, a missed configuration cache update will force the operator to
perform a manual "zfs import" (note -f is not required) to inform the
system about a newly created pool.  To minimize the likelihood of this
rare occurrence, configuration cache write failures now emit FMA events
(via devctl) so the operator can take corrective action, and the write
is retried every 5 minutes.  The retry interval, in seconds, is tunable
via the sysctl "vfs.zfs.ccw_retry_interval".

As a side effect of reporting configuration cache events, other sysevents,
such as re-silver start/stop, are now also reported via devctl.

sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:
	o As is done in zfs_fm.c, provide a manual declaration for
	  devctl_notify().  Both declarations could be combined
	  into spa_impl.h, but the declaration is fault management
	  related, not spa specific.  sys/fm/fs/zfs.h would be ideal
	  if it weren't so public and reserved for FMA string
	  definitions.  I'm open to suggestions on how to improve
	  this nit while minimizing our divergence from Solaris.
	o Use devctl_notify() to implement sysevent support in
	  spa_event_notify().  The subsystem is EC_ZFS so that
	  these events can never collide with those emitted in
	  zfs_fm.c.
	o Add the sysctl "vfs.zfs.ccw_retry_interval".  The value
	  defaults to 5 minutes and is used to rate limit, on a
	  per-pool basis, configuration cache file write attempts.
	o Modify spa_async_dispatch to honor configuration cache
	  write limiting.  If other events are pending, a configuration
	  cache write will be attempted at the same time, so the
	  rate limiting only applies when the asynchronous dispatch
	  system is otherwise idle.  Async events should be rare
	  (e.g. device arrival/departure) and configuration cache
	  writes rarer, so a more complicated system to strictly
	  honor the retry limit seems unwarranted.
	o Remove check in spa_async_dispatch() for the root file
	  system being read-write.

sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c:
	Instead of silently ignoring configuration cache write
	failures, report them via a new FMA event as well as
	to the console.  The current zfs_ereport_post() doesn't
	allow arbitrary name=value pairs to be appended to the
	report, so the configuration cache file name is only
	available on the console output.  This limitation should
	be addressed in a future update.

	Note: This error report is only posted once per incident,
	to avoid spamming.

sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h:
	Add a hrtime_t to the spa data structure to track the
	time (via gethrtime()) of the last configuration cache file
	write failure.  This is referenced in spa_async_dispatch()
	to effect the rate limiting.

sys/cddl/contrib/opensolaris/uts/common/sys/fm/fs/zfs.h:
	  Add FM_EREPORT_ZFS_CONFIG_CACHE_WRITE as an ereport class.

Submitted by:	gibbs
Reviewed by:	Matthew Ahrens <mahrens@delphix.com>,
		Eric Schrock <eric.schrock@delphix.com>,
		Christopher Siden <christopher.siden@delphix.com>
Sponsored by:	Spectra Logic

END