[Gluster-devel] Decomission a brick

[DeeDee Park]

I agree. The "read-only" option is confusing and probably a rename to clarify its function would be helpful. Would something along the lines of "no more additions" be more accurate?

The "hot migrate" is what I'm am looking for. How long before this might be available?

Date: Sat, 15 Dec 2007 06:45:30 +0530
From: avati at zresearch.com
To: deedee6905 at hotmail.com
Subject: Re: [Gluster-devel] Decomission a brick
CC: gluster-devel at nongnu.org

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

this is currently not the way it is. even if you mark a subvolume 'read-only'  in unify, it only means that new files will not be scheduled there. existing files are still modifiable and deletable. (probably read-only is not the right option name). if you _really_ want one subvolume to be equivalent to mounting the disk with "-o ro", you could either


a. actually mount the backend fs with "-o ro" and still glusterfs is happy serving it as-is :)
b. load the filter xlator in the path of that subvolume (either in b/w unify and protocol/client, or in the server spec)


 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.

the hot migrate should address these issues.

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.

_________________________________________________________________
Get the power of Windows + Web with the new Windows Live.
http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007