[Linux-cluster] du takes very long to complete on GFS partition

Martijn Brizee m.brizee at linvision.com
Wed Jun 22 15:15:53 UTC 2005


> > The problem is that a du -s takes about 6 minutes on either partition 
> > every time the command is run. I've mounted the partitions with 
noatime. 
> > Is this a normal time for GFS to do a du run on a 2TB partition? 
> 
> have you ever run `du -s` on a 2TB ext2/ext3 partition?  how about xfs?
Yeah, it's much faster. I don't recall the times exactly, however it's not 
in this order of magnitude.

> 
> i am no expert, but the way i understand things, du will traverse the
> entire inode tree via standard open, read, and lstat syscalls, and add 
all 
> the file sizes together.  therefore, it depends heavily on how many 
files 
> are in the partition.  overall, i think 6 minutes is pretty good for a 
> 2TB partition.
> 
> > When the command ran I noticed a lot of traffic on interface lo. This 
> > seems logical as this node is also running the lockmanager. But what 
> > bothers me is that the traffic does not acceed about 1,5 MB/s avarage. 

> > The loopback interface should be able to handle much more so therefore 

> > it looks that there some sort of bottleneck but I don't see it. Does 
> > anybody have a clue? 
> 
> pardon my ignorance, i've never used redhat's cluster suite.  however,
> what does only 1.5MB/s of traffic on lo have to do with anything?  if
> it's running the lock manager and is doing local communication via lo,
> i think you should be alarmed only if you were seeing a high amount of 
> traffic on lo.  a crapload of traffic across the loopback interface 
would 
> indicate that the system was sending itself data via PF_INET sockets, 
> which just seems like a Wrong Thing To Do as far as efficiency is 
concerned. 

This is what I'm afraid of. When there is no du -s or ls -l running there 
is no data on lo except for some occational DNS traffic. Also the port 
numbers of the traffic on lo indicate that it is lock_gulmd traffic.

thanks,
Martijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20050622/36ad949b/attachment.htm>


More information about the Linux-cluster mailing list