<font><font face="verdana,sans-serif">All the bricks are 3.3, and all the bricks were started via starting glusterd on each of them and then peer-probing etc.</font></font><div><font><font face="verdana,sans-serif"><br></font></font></div>
<div><font><font face="verdana,sans-serif">The initial reason for starting this fix-layout/rebalance/remove brick was a CPU overload on the pbs3 brick (load of >30 on a 4 CPU server) that was dramatically decreasing performance. I killed glusterd, restarted it and checked that it has re-established connection with the 'gluster peer status' command which implied that all 4 peers were connected. I didn't find out until later that this was incorrect using the </font></font><span style="font-family:verdana,sans-serif">'</span><span style="font-family:verdana,sans-serif"> gluster volume status <VOLUME> detail' command. </span></div>
<div><span style="font-family:verdana,sans-serif"><br></span></div><div><span style="font-family:verdana,sans-serif">So this peer has been hashed and thrashed somewhat (and miraculously is still serving files), but in the process, has gone out of proper balance with the other peers.</span></div>
<div><span style="font-family:verdana,sans-serif"><br></span></div><div><span style="font-family:verdana,sans-serif">It sounds like you're saying that this:</span></div><div><span style="font-family:verdana,sans-serif"><br>
</span></div><div><span style="font-family:verdana,sans-serif"><div> Node Rebalanced-files size scanned failures status</div><div> --------- ----------- ----------- ----------- ----------- ------------</div>
<div> localhost 0 0 137702 21406 stopped</div><div> pbs2ib 0 0 168991 6921 stopped</div><div> pbs3ib 724683 594890945282 4402804 0 in progress</div>
<div> pbs4ib 0 0 169081 7923 stopped</div><div><br></div><div>implies that the other peers are not participating in the remove-brick?</div><div>The change in storage across the servers implies that they are participating, just very slowly.</div>
<div><br></div><div>On the other hand the last of the errors stopped 2 days ago (there are no more errors in the last 350MB of the rebalance logs, which also implies that the rest of the files are being migrated, just very slowly..</div>
<div><br></div><div>At any rate, if you've diagnosed the problem, what is the solution? A cluster-wide glusterd restart to sync the uuids? Or is there another way to re-identify them to each other?</div><div><br></div>
<div>Best,</div><div>Harry</div><div><br></div><div><br></div></span></div><div><br><div class="gmail_quote">On Mon, Aug 20, 2012 at 9:06 PM, Shishir Gowda <span dir="ltr"><<a href="mailto:sgowda@redhat.com" target="_blank">sgowda@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Harry,<br>
<br>
Are all the bricks from 3.3? Or did you start any of the bricks manually (not through gluster volume commands) remove-brick/rebalance processes are started across all nodes(1-per node) of the volume.<br>
We use the node-uuid to distribute work across nodes. So migration is handled by all the nodes, to which the data belongs. In your case, there are errors being reported that the node-uuid is not<br>
available.<br>
<br>
With regards,<br>
Shishir<br>
<br>
----- Original Message -----<br>
From: "Harry Mangalam" <<a href="mailto:hjmangalam@gmail.com">hjmangalam@gmail.com</a>><br>
To: "Shishir Gowda" <<a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a>><br>
Cc: "gluster-users" <<a href="mailto:gluster-users@gluster.org">gluster-users@gluster.org</a>><br>
Sent: Tuesday, August 21, 2012 8:37:06 AM<br>
Subject: Re: [Gluster-users] files on gluster brick that have '---------T' designation.<br>
<br>
<br>
Hi Shishir,<br>
<br>
<br>
Here's the 'df -h' of the appropriate filesystem on all 4 of the gluster servers.<br>
It has equilibrated a bit since the original post - pbs3 has decreased from 73% and the others have increased from about 29%, but still, slow.<br>
<br>
<br>
pbs1:/dev/sdb 6.4T 2.0T 4.4T 32% /bducgl<br>
pbs2:/dev/md0 8.2T 2.9T 5.4T 35% /bducgl<br>
pbs3:/dev/md127 8.2T 5.3T 3.0T 65% /bducgl<br>
pbs4:/dev/sda 6.4T 2.2T 4.3T 34% /bducgl<br>
<br>
<br>
The 'errors-only' extract of the log (since the remove-brick was started) is here:<br>
< <a href="http://moo.nac.uci.edu/~hjm/gluster/remove-brick_errors.log.gz" target="_blank">http://moo.nac.uci.edu/~hjm/gluster/remove-brick_errors.log.gz</a> > (2707 lines)<br>
and the last 100 lines of the active log (gli-rebalance.log) is here:<br>
< <a href="http://pastie.org/4559913" target="_blank">http://pastie.org/4559913</a> ><br>
<br>
<br>
Thanks for your help.<br>
Harry<br>
<br>
On Mon, Aug 20, 2012 at 7:42 PM, Shishir Gowda < <a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a> > wrote:<br>
<br>
<br>
Hi Harry,<br>
<br>
That is correct, the files wont be seen on the client.<br>
Can you provide an output of these:<br>
1. df of all exports<br>
2. Provide remove-brick/rebalance (<volname>-rebalance.log) log (if large just the failure messages, and tail of the the file).<br>
<br>
With regards,<br>
Shishir<br>
<br>
----- Original Message -----<br>
From: "Harry Mangalam" < <a href="mailto:hjmangalam@gmail.com">hjmangalam@gmail.com</a> ><br>
To: "Shishir Gowda" < <a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a> ><br>
Cc: "gluster-users" < <a href="mailto:gluster-users@gluster.org">gluster-users@gluster.org</a> ><br>
Sent: Tuesday, August 21, 2012 8:00:42 AM<br>
Subject: Re: [Gluster-users] files on gluster brick that have '---------T' designation.<br>
<br>
Hi Shishir,<br>
<br>
<br>
Thanks for your attention.<br>
<br>
<br>
<br>
Hmm - your explanation makes some sense, but those 'T' files don't show up in the client view of the dir - only in the brick view. Is that valid?<br>
<br>
<br>
I'm using 3.3 on 4 ubuntu 12.04 servers over DDR IPoIB, and the command to initiate the remove brick was:<br>
<br>
<br>
$ gluster volume remove-brick gli pbs3ib:/bducgl start<br>
<br>
<br>
and the current status is:<br>
<br>
<br>
<br>
$ gluster volume remove-brick gli pbs3ib:/bducgl status<br>
Node Rebalanced-files size scanned failures status<br>
--------- ----------- ----------- ----------- ----------- ------------<br>
localhost 0 0 137702 21406 stopped<br>
pbs2ib 0 0 168991 6921 stopped<br>
pbs3ib 724683 594890945282 4402804 0 in progress<br>
pbs4ib 0 0 169081 7923 stopped<br>
<br>
<br>
(the failures were the same as were seen as when I tried the rebalance command previously).<br>
<br>
<br>
Best<br>
harry<br>
<br>
<br>
On Mon, Aug 20, 2012 at 7:09 PM, Shishir Gowda < <a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a> > wrote:<br>
<br>
<br>
Hi Harry,<br>
<br>
These are valid files in glusterfs-dht xlator configured volumes. These are known as link files, which dht uses to maintain files on the hashed subvol, when the actual data resides in non hashed subvolumes(rename can lead to these). The cleanup of these files will be taken care of by running rebalance.<br>
Can you please provide the gluster version you are using, and the remove brick command you used?<br>
<br>
With regards,<br>
Shishir<br>
<br>
----- Original Message -----<br>
From: "Harry Mangalam" < <a href="mailto:hjmangalam@gmail.com">hjmangalam@gmail.com</a> ><br>
To: "gluster-users" < <a href="mailto:gluster-users@gluster.org">gluster-users@gluster.org</a> ><br>
Sent: Tuesday, August 21, 2012 5:01:05 AM<br>
Subject: [Gluster-users] files on gluster brick that have '---------T' designation.<br>
<br>
<br>
I have a working but unbalanced gluster config where one brick has about 2X the usage of the 3 others. I started a remove-brick to force a resolution of this problem (Thanks to JD for the help!), but it's going very slowly, about 2.2MB/s over DDR IPoIB or ~2.3 files/s. In investigating the problem, I may have found a partial explanation - I have found 100s of thousands (maybe millions) of zero-length files existing on the problem brick that do not exist on the client view that have the designation ' ---------T' via 'ls -l'<br>
<br>
<br>
ie:<br>
<br>
<br>
<br>
/bducgl/alamng/Research/Yuki/newF20/runF20_2513/data:<br>
total 0<br>
---------T 2 root root 0 2012-08-04 11:23 backward_sm1003<br>
---------T 2 root root 0 2012-08-04 11:23 backward_sm1007<br>
---------T 2 root root 0 2012-08-04 11:23 backward_sm1029<br>
<br>
<br>
I suspect that these are the ones that are responsible for the enormous expansion of the storage space on this brick and the very slow speed of the 'remove-brick' operation.<br>
<br>
<br>
Does this sound possible? Can I delete these files on the brick to resolve the imbalance? If not, is there a way to process them in some better way to rationalize the imbalance?<br>
<br>
--<br>
Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine<br>
[m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487<br>
415 South Circle View Dr, Irvine, CA, 92697 [shipping]<br>
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)<br>
<br>
<br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://gluster.org/cgi-bin/mailman/listinfo/gluster-users</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
--<br>
Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine<br>
[m/c 2225] / 92697 Google Voice Multiplexer: <a href="tel:%28949%29%20478-4487" value="+19494784487">(949) 478-4487</a><br>
415 South Circle View Dr, Irvine, CA, 92697 [shipping]<br>
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine<br>
[m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487<br>
415 South Circle View Dr, Irvine, CA, 92697 [shipping]<br>
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine<br>[m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487<br>415 South Circle View Dr, Irvine, CA, 92697 [shipping]<br>
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)<br><br>
</div>