Hello, there have been some threads in the past about 'ls' being slow on large file directories but my question is more regarding documentation: According to http://www.gluster.org/docs/index.php/GlusterFS_FAQ - "Just doing "ls" doesn't trigger stat call. It should be fast as this is called only on the namespace child." But actually on our system/setup (where namespace resides on seperate partition (c0d0) and the storage bricks are different pairs of disks (c1d0-c2d6) mounted together with unify) we see that after doing 'ls' a sequence starts which reads every storage brick (and not only namespace). In iostat it looks something like this (I hope the spacing won't break): avg-cpu: %user %nice %system %iowait %steal %idle 0.00 0.00 0.50 0.00 0.00 99.50 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn cciss/c0d0 0.00 0.00 0.00 0 0 cciss/c1d0 0.00 0.00 0.00 0 0 cciss/c1d1 0.00 0.00 0.00 0 0 cciss/c1d2 0.00 0.00 0.00 0 0 cciss/c1d3 189.00 3008.00 0.00 3008 0 cciss/c1d4 0.00 0.00 0.00 0 0 cciss/c1d5 0.00 0.00 0.00 0 0 cciss/c1d6 0.00 0.00 0.00 0 0 cciss/c1d7 0.00 0.00 0.00 0 0 cciss/c1d8 0.00 0.00 0.00 0 0 cciss/c1d9 0.00 0.00 0.00 0 0 cciss/c2d0 0.00 0.00 0.00 0 0 cciss/c2d1 0.00 0.00 0.00 0 0 cciss/c2d2 0.00 0.00 0.00 0 0 cciss/c2d3 0.00 0.00 0.00 0 0 cciss/c2d4 0.00 0.00 0.00 0 0 cciss/c2d5 0.00 0.00 0.00 0 0 cciss/c2d6 0.00 0.00 0.00 0 0 There is only one partition being read at time when it finishes it switches to the next. Sometimes the loop goes even 2 or 3 times before the directory/file listing is returned. So it takes pretty long after the mounted partition becomes responsive. I wonder is it supposed to be so or the 'ls' from OpenSuse "breaks" the whole thing (because it adds some commandline params on its own - full command looks like 'ls -N --color=tty -T 0 -1') wbr Reinis Rozitis
