> 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
