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