Slow start when current directory is on CIFS/SMB share

Bug #1625739 reported by Fuujuhi
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mc (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

MC is very slow to start (several seconds) when current directory is on a CIFS/SMB share. Also the subshell / menu switch (with C-o) is very slow when switching back to the menu, which is annoying.

Using ''strace'' I could narrow down the problem to a call to stat(2):

$ cd /smb/lacie-cloudbox/myshare

$ mount|grep lacie-cloudbox
//lacie-cloudbox/myshare on /smb/lacie-cloudbox/myshare type cifs (rw)

$ strace -r -tt -o /tmp/mc.strace mc
$ grep -v 0.0 /tmp/mc.strace
     3.310479 stat("/smb/lacie-cloudbox/myshare", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0

Note that this is a long due issue (was already in 12.04 and probably before), but it is only lately that I could narrow down the problem as highlighted above.

$ lsb_release -rd
Description: Ubuntu 14.04.5 LTS
Release: 14.04

$ apt-cache policy mc
mc:
  Installed: 3:4.8.11-1
  Candidate: 3:4.8.11-1
  Version table:
 *** 3:4.8.11-1 0
        500 http://be.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Yury V. Zaytsev (zyv) wrote :

So, why the stat call is taking so long, is it really an mc problem, i.e. if you just make the call outside of mc, does it also take a long time?

Revision history for this message
Fuujuhi (fuujuhi) wrote :

Well, sorry I did not mention that, but indeed, it also take a long time outside of mc.
Typically, a `stat -f /smb/lacie-cloudbox/myshare` is also slow.

Also, mc is not always slow on CIFS/SMB shares. At first sight, it seems to depend on the server speed & load (nothing new here I guess).

So, to rephrase, the problem is not really that mc is slow on CIFS/SMB shares, but is that it makes IO calls that are potentially slow, like stat'ing a directory tree on the network. The problem I have is that I heavily rely on mc for browsing directory structures, but sometimes, when browsing over the network, I have to go to sub-shell because of performance issue, and browse manually with `cd` commands, which is not convenient.

What I would like is to keep using mc for all browsing, and have mc not doing any IO that might be potentially slow. Only do the minimum necessary IO to display the current directory. For instance, I would happily give up the display of the total used size / total available size if that can speed up IO.

Revision history for this message
Yury V. Zaytsev (zyv) wrote :

I see, thanks for the clarification. It seems that you have some kind of a problem with your setup, be it a misconfiguration or a CIFS client bug.

Unfortunately, we can't remove stat calls from mc: it basically uses it for everything in the world, i.e. mode & ownership information, access & modification times, sizes, etc.

I think that it's most promising for you to try to find out why these calls take so long and fix your setup (or else good luck trying to patch stat calls out of mc, look for the mc_stat function), and this report should rather be rejected.

Revision history for this message
Fuujuhi (fuujuhi) wrote :

Actually I know that my SMB server is overloaded (it also serves as backup server, running rsync and co). It's only that you don't feel that it is loaded when browsing with ls/cd commands and bash completion, whereas you feel it significantly when using mc.

I any case I would understand if you reject the report since my case is quite specific. Actually it's more like a feature request than a bug report. Thanks already a lot for your time and fast response. Maybe one day I'll look into this mc_stat function ;-)

Revision history for this message
Yury V. Zaytsev (zyv) wrote :

Sorry, I wish I could have helped you with something more substantial, but, as I said, unfortunately, I see no practical way of reducing the amount of stat calls that mc makes :-/

Changed in mc (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.