<tt>> > 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? </tt> <tt>> </tt> <tt>> have you ever run `du -s` on a 2TB ext2/ext3 partition? how about xfs?</tt> <tt>Yeah, it's much faster. I don't recall the times exactly, however it's not in this order of magnitude.</tt> <tt>> </tt> <tt>> 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 </tt> <tt>> the file sizes together. therefore, it depends heavily on how many files </tt> <tt>> are in the partition. overall, i think 6 minutes is pretty good for a </tt> <tt>> 2TB partition.</tt> <tt>> </tt> <tt>> > 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? </tt> <tt>> </tt> <tt>> 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 </tt> <tt>> traffic on lo. a crapload of traffic across the loopback interface would </tt> <tt>> indicate that the system was sending itself data via PF_INET sockets, </tt> <tt>> which just seems like a Wrong Thing To Do as far as efficiency is concerned. </tt> <tt>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.</tt> <tt>thanks,</tt> <tt>Martijn</tt>