> > 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
-- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
