> currently you can mark certain subvolumes as read-only in unify to do this. Would then the files be copied to a different brick when the files are opened during a "find /mnt/glusterfs"? The feature would be a little more than just making it read-only. It would have to allow files to get offloaded and removed from the brick while still being in service. I assume the read-only would still make it possible to have only one copy on the decomissioned brick. Date: Sat, 15 Dec 2007 01:39:56 +0530 From: avati@xxxxxxxxxxxxx To: deedee6905@xxxxxxxxxxx Subject: Re: Decomission a brick CC: gluster-devel@xxxxxxxxxx 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. _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007
