On 2010-Jul-08 02:39:05 +0800, Garrett D'Amore <garr...@nexenta.com> wrote:
>I believe that long term folks are working on solving this problem.  I
>believe bp_rewrite is needed for this work.

Accepted.

>Mid/short term, the solution to me at least seems to be to migrate your
>data to a new zpool on the newly configured array, etc.

IMHO, this isn't an acceptable solution.

Note that (eg) DEC/Compaq/HP AdvFS has supported vdev removal from day
1 and (until a couple of years ago), I had an AdvFS pool that had,
over a decade, grown from a mirrored pair of 4.3GB disks to six pairs
of mirrored 36GB disks - without needing any downtime for disk
expansion.  [Adding disks was done with mirror pairs because AdvFS
didn't support any RAID5/6 style redundancy, the big win was being
able to remove older vdevs so those disk slots could be reused].

>  Most
>enterprises don't incrementally upgrade an array (except perhaps to add
>more drives, etc.)

This isn't true for me.  It is not uncommon for me to replace an xGB
disk with a (2x)GB disk to expand an existing filesystem - in many
cases, it is not possible to add more drives because there are no
physical slots available.  And, one of the problems with ZFS is that,
unless you don't bother with any data redundancy, it's not possible to
add single drives - you can only add vdevs that are pre-configured with
the desired level of redundancy.

>  Disks are cheap enough that its usually not that
>hard to justify a full upgrade every few years.  (Frankly, spinning rust
>MTBFs are still low enough that I think most sites wind up assuming that
>they are going to have to replace their storage on a 3-5 year cycle
>anyway.  We've not yet seen what SSDs do that trend, I think.)

Maybe in some environments.  We tend to run equipment into the ground
and I know other companies with similar policies.  And getting approval
for a couple of thousand dollars of new disks is very much easier than
getting approval for a complete new SAN with (eg) twice the capacity
of the existing one.

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

Reply via email to