> > 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.
