zfs discuss - Apr 2007 - Permanently removing vdevs from a pool

Is it possible to gracefully and permanently remove a vdev from a pool without
data loss? The type of pool in question here is a simple pool without
redundancies (i.e. JBOD). The documentation mentions for instance offlining, but
without going into the end results of doing that. The thing I''m looking
for is an option to evacuate, for the lack of a better word, the data from a
specific vdevs to the other vdevs in the pool, so the device can simply be
removed.

Scenarios for this would be inavailability of spares (this actually happened to
me, in a fairly huge computer wholesales none the less (sad chapter)) and disk
replacements in an end user scenario.

Thanks.
 
 
This message posted from opensolaris.org

On Thu, 19 Apr 2007, Mario Goebbels wrote:
> Is it possible to gracefully and permanently remove a vdev from a pool
> without data loss?
Is this what you''re looking for?
	http://bugs.opensolaris.org/view_bug.do?bug_id=4852783

If so, the answer is ''not yet''.


Regards,
markm

On 4/19/07, Mark J Musante <mmusante at east.sun.com>
wrote:
> On Thu, 19 Apr 2007, Mario Goebbels wrote:
>
> > Is it possible to gracefully and permanently remove a vdev from a pool
> > without data loss?
>
> Is this what you''re looking for?
>         http://bugs.opensolaris.org/view_bug.do?bug_id=4852783
>
> If so, the answer is ''not yet''.
Can the ZFS team comment on how far out this feature is? There are a
couple of items 9and bugs) that are preventing us from deploying ZFS,
and this is one of them.

Thanks for any insight,
- Ryan
-- 
UNIX Administrator
http://prefetch.net

On Thu, 2007-04-19 at 11:59 -0700, Mario Goebbels wrote:
> Is it possible to gracefully and permanently remove a vdev from a pool
> without data loss? 
Not yet.  But it''s on lots of people''s wishlists,
there''s an open RFE,
and members of the zfs team have said on this list that they''re working
on it..

Bugid is:

4852783 reduce pool capacity

						- Bill

Mario,

Until zpool remove is available, you don''t have any options to remove a
disk from a non-redundant pool.

Currently, you can:

- replace or detach a disk in a ZFS mirrored storage pool
- replace a disk in a ZFS RAID-Z storage pool

Please see the ZFS best practices site for more info about using
redundant ZFS configurations:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

Cindy

Mario Goebbels wrote:
> Is it possible to gracefully and permanently remove a vdev from a pool
without data loss? The type of pool in question here is a simple pool without
redundancies (i.e. JBOD). The documentation mentions for instance offlining, but
without going into the end results of doing that. The thing I''m looking
for is an option to evacuate, for the lack of a better word, the data from a
specific vdevs to the other vdevs in the pool, so the device can simply be
removed.
> 
> Scenarios for this would be inavailability of spares (this actually
happened to me, in a fairly huge computer wholesales none the less (sad
chapter)) and disk replacements in an end user scenario.
> 
> Thanks.
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

This is a high priority for us and is actively being worked.

Vague enough for you. :-) Sorry I can''t give you anything more exact 
that that.

- George

Matty wrote:
> On 4/19/07, Mark J Musante <mmusante at east.sun.com> wrote:
>> On Thu, 19 Apr 2007, Mario Goebbels wrote:
>>
>> > Is it possible to gracefully and permanently remove a vdev from a
pool
>> > without data loss?
>>
>> Is this what you''re looking for?
>>         http://bugs.opensolaris.org/view_bug.do?bug_id=4852783
>>
>> If so, the answer is ''not yet''.
>
> Can the ZFS team comment on how far out this feature is? There are a
> couple of items 9and bugs) that are preventing us from deploying ZFS,
> and this is one of them.
>
> Thanks for any insight,
> - Ryan

Hello George,

Friday, April 20, 2007, 7:37:52 AM, you wrote:

GW> This is a high priority for us and is actively being worked.

GW> Vague enough for you. :-) Sorry I can''t give you anything more
exact
GW> that that.

Can you at least give us feature list being developed?

Some answers to questions like:

1. evacuating a vdev resulting in a smaller pool for all raid configs - ?

2. adding new vdev and rewriting all existing data to new larger
   stripe - ?

3. expanding stripe width for raid-z1 and raid-z2 - ?

4. live conversion between different raid kinds on the same disk set - ?

5. live data migration from one disk set to another - ?
   [if 1 works it should be simple - first force adding new disks,
    even if with different redundancy scheme then evacuate old disks.
    This also partly solves 5 but you need different disks.]

6. rewriting data in a dataset (not entire pool) after changing some
   parameters like compression, encryption, ditto blocks, ... so it
   will affect also already written data in a dataset. This should be
   both pool wise and data set wise - ?

7. de-fragmentation of a pool - ?

8. anything else ?


-- 
Best regards,
 Robert                            mailto:rmilkowski at task.gda.pl
                                       http://milek.blogspot.com

On 4/20/07, George Wilson <George.Wilson at sun.com>
wrote:
> This is a high priority for us and is actively being worked.
>
> Vague enough for you. :-) Sorry I can''t give you anything more
exact
> that that.
Hi George,

If ZFS is supposed to be part of "open"solaris, then why
can''t the
community get additional details? If really seems like much of the
development and design of ZFS goes on behind closed doors, and the
community as a whole is involved after the fact (Eric Shrock has
requested feedback from list members, which is awesome!). This makes
it difficult for folks to contribute, and to offer suggestions (or
code) that would better ZFS as a whole. Is there a reason that more of
the ZFS development discussions aren''t occuring in public?

Thanks,
- Ryan
-- 
UNIX Administrator
http://prefetch.net

Knowing that this is a planned feature and the ZFS team is actively working on
it answers my question more than expected. Thanks.
 
 
This message posted from opensolaris.org

Matty wrote:
> On 4/20/07, George Wilson <George.Wilson at sun.com> wrote:
>> This is a high priority for us and is actively being worked.
>>
>> Vague enough for you. :-) Sorry I can''t give you anything more
exact
>> that that.
>
> Hi George,
>
> If ZFS is supposed to be part of "open"solaris, then why
can''t the
> community get additional details? If really seems like much of the
> development and design of ZFS goes on behind closed doors, and the
> community as a whole is involved after the fact (Eric Shrock has
> requested feedback from list members, which is awesome!). This makes
> it difficult for folks to contribute, and to offer suggestions (or
> code) that would better ZFS as a whole. Is there a reason that more of
> the ZFS development discussions aren''t occuring in public?
>
I can''t speak for the zpool-shrink work, but I''ve been
inspired (partly
by this post) to start collecting more input from the community regarding
the use of zfs as a root file system.  I''ve just started a blog
(http://blogs.sun.com/lalt/) and I''ll be putting out posts
there and on this alias regarding some of the design issues that need
to get resolved.   So watch for it.

Lori

Robert Milkowski wrote:
> Hello George,
> 
> Friday, April 20, 2007, 7:37:52 AM, you wrote:
> 
> GW> This is a high priority for us and is actively being worked.
> 
> GW> Vague enough for you. :-) Sorry I can''t give you anything
more exact
> GW> that that.
> 
> Can you at least give us feature list being developed?
> 
> Some answers to questions like:
> 
> 1. evacuating a vdev resulting in a smaller pool for all raid configs - ?
> 
> 2. adding new vdev and rewriting all existing data to new larger
>    stripe - ?
> 
> 3. expanding stripe width for raid-z1 and raid-z2 - ?
> 
> 4. live conversion between different raid kinds on the same disk set - ?
No, you will not be able to change the number of disks in a raid-z set 
(I think that answers questions 1-4).  There is no plan to implement 
this feature.
> 5. live data migration from one disk set to another - ?
Yes -- just add the new disk set, then remove the old disk set.
> 6. rewriting data in a dataset (not entire pool) after changing some
>    parameters like compression, encryption, ditto blocks, ... so it
>    will affect also already written data in a dataset. This should be
>    both pool wise and data set wise - ?
Yes.
> 7. de-fragmentation of a pool - ?
Yes.
> 8. anything else ?
--matt

Matty wrote:
> On 4/20/07, George Wilson <George.Wilson at sun.com> wrote:
>> This is a high priority for us and is actively being worked.
>>
>> Vague enough for you. :-) Sorry I can''t give you anything more
exact
>> that that.
> 
> Hi George,
> 
> If ZFS is supposed to be part of "open"solaris, then why
can''t the
> community get additional details?
What additional details would you like?  We are not withholding anything 
-- George answered the question to the best of his knowledge.  We simply 
aren''t sure when exactly this feature will be completed.

--matt

> > 1. evacuating a vdev resulting in a smaller pool
> for all raid configs - ?
> > 
> > 2. adding new vdev and rewriting all existing data
> to new larger
> >    stripe - ?
> > 
> > 3. expanding stripe width for raid-z1 and raid-z2 -
> ?
> > 
> > 4. live conversion between different raid kinds on
> the same disk set - ?
> 
> No, you will not be able to change the number of
> disks in a raid-z set 
> (I think that answers questions 1-4).  There is no
> plan to implement 
> this feature.
Am I interpreting this correctly that there are no plans to allow expansion of
raid-z vdevs?  This is one feature that I see as critical for home users who may
not have case/sata or ide connector space to add a larger vdev when the time
comes for expansion of a pool.
 
 
This message posted from opensolaris.org

> > No, you will not be able to change the number of
> > disks in a raid-z set 
> > (I think that answers questions 1-4).  There is no
> > plan to implement 
> > this feature.
>
> Am I interpreting this correctly that there are no plans to allow
> expansion of raid-z vdevs?  This is one feature that I see as critical
> for home users who may not have case/sata or ide connector space to
> add a larger vdev when the time comes for expansion of a pool.
I would hope that someone looks at it again after the "rewrite" or
whatever function to refresh all data makes it it.  It seems to me that
adding to a raid-z vdev is trival (although understanding the
implications of that addition may not be as simple).

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

I found this feature to be incredibly useful when managing a Digital Unix system
with AdsFS.  Migrating to a larger disk (or larger hardware RAID set) was a
simple "add", "remove" and wait for the filesystem to clean
up.  This was done with multiple users online.  Good Stuff !

Keep up the good work !
 
 
This message posted from opensolaris.org