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

[Eldridge, Michael]

> 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?
 
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. 
 
again, i am very ignorant when it comes to RH cluster suite  (i have only
been on this list for ~3 weeks and have never used the product), but i don't
think anything is wrong with your setup.  it is my opinion that you are being 
overly paranoid.  ;) 
 
take it with a grain of salt, though. 
 
-mike 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20050622/a20f13a2/attachment.htm>