Yes, that is the intended use case. We are ironing out details especially when hardlinks exist on the decommissioning node. Any feedback on how this works for you is most appreciated.
Avati On Fri, Mar 16, 2012 at 8:35 PM, Joe Landman < [email protected]> wrote: > This is an important bit of functionality, one we are running head first > into. > > Here's the scenario: You have N bricks in your system. You want to > reduce this by one (or more), and you have enough storage to shrink this. > > Can we do something like a > > gluster volume decommission-brick volume_name brick1:/path1 ... > > so that it starts moving data off the brick onto other bricks, and upon > completion, it marks the brick as ready to be removed? > > Assume this is a very useful use case. Telling a user that they have > mandatory down time (e.g. missing some files) to do this now is not a > selling point. > > Is this, or something very close to this in 3.3beta? > > -- > Joseph Landman, Ph.D > Founder and CEO > Scalable Informatics Inc. > email: landman@scalableinformatics.**com <[email protected]> > web : http://scalableinformatics.com > > http://scalableinformatics.**com/sicluster<http://scalableinformatics.com/sicluster> > phone: +1 734 786 8423 x121 > fax : +1 866 888 3112 > cell : +1 734 612 4615 > > ______________________________**_________________ > Gluster-users mailing list > [email protected] > http://gluster.org/cgi-bin/**mailman/listinfo/gluster-users<http://gluster.org/cgi-bin/mailman/listinfo/gluster-users> >
_______________________________________________ Gluster-users mailing list [email protected] http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
