<font><font face="verdana,sans-serif">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 '</font></font><font face="verdana, sans-serif">---------T' via 'ls -l'</font><div>
<font face="verdana, sans-serif"><br></font><div><font><font face="verdana,sans-serif">ie:</font></font></div><div><font><font face="verdana,sans-serif"><br clear="all"></font></font><div><div>/bducgl/alamng/Research/Yuki/newF20/runF20_2513/data:</div>
<div>total 0</div><div>---------T 2 root root 0 2012-08-04 11:23 backward_sm1003</div><div>---------T 2 root root 0 2012-08-04 11:23 backward_sm1007</div><div>---------T 2 root root 0 2012-08-04 11:23 backward_sm1029</div>
</div><div><br></div><div>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.</div><div><br>
</div><div>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?</div><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></div>