Gluster users - Aug 2012 - files on gluster brick that have '---------T' designation.

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'

ie:

/bducgl/alamng/Research/Yuki/newF20/runF20_2513/data:
total 0
---------T 2 root root 0 2012-08-04 11:23 backward_sm1003
---------T 2 root root 0 2012-08-04 11:23 backward_sm1007
---------T 2 root root 0 2012-08-04 11:23 backward_sm1029

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.

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?

-- 
Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine
[m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487
415 South Circle View Dr, Irvine, CA, 92697 [shipping]
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20120820/79fa373b/attachment.html>

Hi Harry,

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.
Can you please provide the gluster version you are using, and the remove brick
command you used?

With regards,
Shishir

----- Original Message -----
From: "Harry Mangalam" <hjmangalam at gmail.com>
To: "gluster-users" <gluster-users at gluster.org>
Sent: Tuesday, August 21, 2012 5:01:05 AM
Subject: [Gluster-users] files on gluster brick that have '---------T'
designation.


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'


ie: 



/bducgl/alamng/Research/Yuki/newF20/runF20_2513/data: 
total 0 
---------T 2 root root 0 2012-08-04 11:23 backward_sm1003 
---------T 2 root root 0 2012-08-04 11:23 backward_sm1007 
---------T 2 root root 0 2012-08-04 11:23 backward_sm1029 


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.


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?

-- 
Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine 
[m/c 2225] / 92697 Google Voice Multiplexer: (949) 478-4487 
415 South Circle View Dr, Irvine, CA, 92697 [shipping] 
MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps) 


_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users