Re: [Gluster-devel] Decomission a brick

[Anand Avati]

>
> Thanks, the concept makes sense. I would be using the unify scenario you
> gave, but it requires
> effectively a downtime while the brick is rsynced back into the
> /mnt/glusterfs. It does take quite a bit
> of time to get large quantites of data transferred back into the active
> file system.
>
> I would like to see a feature where I can still keep the brick active, yet
> all *new* file accesses or creations would not use the brick that was
> planned for decomission.
>

currently you can mark certain subvolumes as read-only in unify to do this.


This way as the regularly used files are then moved off to other bricks by
> normal use, and over time there would be less to transfer from the
> decomissioning brick. Isn't there some way to do this in the spec file so
> that no more files are written to the brick?
>
> I was thinking something more like
> 1) set available disk size to zero for the brick
> 2) find /mnt/glusterfs (this would move the files out of the full or
> decomissioned brick)
>

this would not move files out.
we'll keep the list updated with the progress about hot migration.

avati


-- 
If I traveled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.