On Sat, Feb 28, 2009 at 05:19:26PM -0600, Mike Gerdts wrote:
> On Sat, Feb 28, 2009 at 4:33 PM, Nicolas Williams
> <nicolas.willi...@sun.com> wrote:
> > On Sat, Feb 28, 2009 at 10:44:59PM +0100, Thomas Wagner wrote:
> >> > >> pool-shrinking (and an option to shrink disk A when i want disk B to
> >> > >> become a mirror, but A is a few blocks bigger)
> >> >  This may be interesting... I'm not sure how often you need to shrink a 
> >> > pool
> >> >  though?  Could this be classified more as a Home or SME level feature?
> >>
> >> Enterprise level especially in SAN environments need this.
> >>
> >> Projects own theyr own pools and constantly grow and *shrink* space.
> >> And they have no downtime available for that.
> >
> > Multiple pools on one server only makes sense if you are going to have
> > different RAS for each pool for business reasons.  It's a lot easier to
> > have a single pool though.  I recommend it.
> 
> Other scenarios for multiple pools include:
> 
> - Need independent portability of data between servers.  For example,
> in a HA cluster environment, various workloads will be mapped to
> various pools.  Since ZFS does not do active-active clustering, a
> single pool for anything other than a simple active-standby cluster is
> not useful.

Right, but normally each head in a cluster will have only one pool
imported.

The Sun Storage 7xxx do this.  One pool per-head, two pools altogether
in a cluster.

> - Array based copies are needed.  There are times when copies of data
> are performed at a storage array level to allow testing and support
> operations to happen "on different spindles".  For example, in a
> consolidated database environment, each database may be constrained to
> a set of spindles so that each database can be replicated or copied
> independent of the various others.

This gets you back into managing physical space allocation.  Do you
really want that?  If you're using zvols you can do "array based copies"
of you zvols.  If you're using filesystems then you should just use
normal backup tools.

Nico
-- 
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to