2008/353 [zpool autoexpand property]

[Richard L. Hamilton]

> Glenn Skinner wrote:
> >     Date: Fri, 30 May 2008 15:19:45 -0700 (PDT)
> >     From: Matthew Ahrens <ahrens at sac.sfbay.sun.com>
> >     Subject: zpool autoexpand property
> [PSARC/2008/353 Self Review]
> > 
> >     ...
> >     B. PROBLEM
> > 
> >     With the addition of Dynamic LUN Expansion
> (PSARC 2006/373),
> >     Solaris now publishes a sysevent when an
> underlying device is
> >     expanded.  ZFS has been enhanced to take
> advantage of these events
> >     and will adjust the pool based on the new size
> of the expanded
> >     LUN.  However, administrators need the ability
> to control this
> >     behavior on individual pools.
> > 
> >     C. PROPOSED SOLUTION
> > 
> >     The introduction of the 'autoexpand' will allow
> administrators the
> >     ability to enable or disable automatic pool
> expansion when a
> >     Dynamic LUN Expansion event is received.  The
> syntax for setting
> >     the pool property utilizes the "set" subcommand
> defined in PSARC
> >     2006/577:
> > 
> >        # zpool set autoexpand=on <pool>
> >        # zpool create -o autoexpand=on <pool>
> <device> ..
> > 
> > I'm nearly certain I'm failing to see the obvious,
> but could you
> > explain why an administrator would ever want this
> property to be set
> > to "off"?
> 
> If you have a mirror with non-identical disks, one
> will be bigger
> than the other, even just by a few sectors. If you
> temporarily
> detach the smaller one, you unexpectedly find can't
> attach it again
> if the pool auto-expands to a larger size. This has
> hit a number
> of people. Similarly, SVM does not expand metadevices
> until
> explicitly told to do so, which I believe is a
> sensible default
> and avoids this problem.

Then couldn't there be some way to change the setting to off when
a mirror is detached?  Given your scenario, that (along with a message
advising of the change) might be safer even if the default is off.
 
 
This message posted from opensolaris.org