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

["Martijn Brizee" <m brizee linvision com>]

> > 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