[Gluster-users] what happens when adding a pre-populated brick?

[Harry Mangalam]

Thanks very much for the answer, Jeff.  Lacking further info, I'll 
hang out on the gluster irc and over the break, try it out on an 
experimental volume.

hjm

On Friday 16 December 2011 07:43:06 Jeff White wrote:
> I have been told this is do-able but I haven't tested it much
> myself.  I would be interested in hearing about this from anyone
> who has done it.
> 
>  From what I heard on irc you can do the following:
> 
> 1. Have existing data in server1:/data1
> 2. Stop all changes to server1:/data1
> 3. Create a volume: gluster volume create....server1:/data1
> server2:/data2 4. Mount the new volume via FUSE
> 5. Trigger a self-heal: find gluster-mount -noleaf -print0 | xargs
> --null stat >/dev/null
> 
> I also heard that there could be GFID problem if the data was
> previously in another Gluster volume.
> 
> Jeff White - Linux/Unix Systems Engineer
> University of Pittsburgh - CSSD
> 
> On 12/15/2011 01:48 PM, Harry Mangalam wrote:
> > The use case is that we have a multiTB data partition that we
> > would like to glusterize. Could we add that store to a gluster
> > volume and have it explicitly rebalance across the gluster
> > volume? Or would the existing files/layout be ignored?
> > 
> > this would be a big selling point in justifying gluster to owners
> > of large existing data stores.
> > 
> > 
> > Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine
> > 
> > [ZOT 2225] / 92697 Google Voice Multiplexer: (949) 478-4487
> > 
> > MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)
> > 
> > --
> > 
> > This signature has been OCCUPIED!

-- 
Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine
[ZOT 2225] / 92697  Google Voice Multiplexer: (949) 478-4487 
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)
--
This signature has been OCCUPIED!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20111216/ab55c34b/attachment.html>