1

I've got a server that has a cifs share (Azure storage files) mounted. Sometimes ls is returning slowly (20seconds). After debugging a bit I've so far found that:

  • doing ls /data/some/symlink/directory return in 20 seconds
  • going into the /data/some/symlink/directory and then doing ls . takes 0.02 seconds
  • doing ls /data/original/location/that/symlinkpoints/to/directory also returns sub second

the 20 second return time for ls seems to be affected by the number of files in the directory. The larger the directory the more time it takes.

This made me think it had something to do with how the symlink was being treated by ls. Like it had to resolve it for every file or something.

In order to debug this I wanted to run ls through strace to see if I could see what the difference was in syscalls between the different cases. However if I run 

strace ls /data/some/symlink/directory it also returns sub second suddenly.

Any ideas on why running it through strace is making it fast and how to debug further?

olle
  • 151
  • 6

1 Answers1

4

Turned out to be an alias for ls /home/someuser/.bashrc: alias ls='ls --color=auto'

the --color=auto option is causing ls to return colors in my terminal but not in strace. In order to support the colors it needs to stat the files.

olle
  • 151
  • 6
  • Also, it tends to be useful to consider getting ls to return items not in a sorted order. The `-f` option disables colour output and sorting. ("do not sort, enable -aU, disable -ls --color") – Cameron Kerr Aug 18 '18 at 11:17
  • The `--color=auto` option would also cause colors in strace. However strace doesn't expand a shell alias, and therefor `ls` runs without that option. – RalfFriedl Aug 18 '18 at 13:00