Re: dired too SLOW

[Paul Eggert <eggert@twinsun.com>]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 8 Mar 2002 14:07:17 -0700 (MST)
> 
>     I had this problem and commented-out the invocation of "df",
>     from: insert-directory.el
> 
> It is very strange that df should be so slow.
> Normally it is very fast.  What is causing it to be slow?

There are many reasons df could be slow.  I have often run into
automounters or NFS servers that take a long time to respond to a
resolvepath or a statvfs system call (which df uses), even when they
respond quickly to a stat system call (which ls uses).  This can be
caused by stale NFS file handles, for example.

I've heard that some HP-UX releases require that every mountable
filesystem must actually be mounted, or df will hang.  This might be
what buff is running into, since he's at HP.

In some cases (the Solaris 2.6 automounter comes to mind), the problem
can be worked around by doing the stat (or ls) before the statvfs (or df).
It might be wise to modify Emacs to do that.

Also, perhaps Emacs could put a short timeout on its invocation to
'df', and report that the usage is unknown if 'df' fails to respond in
time.

On older BSD hosts like SunOS 4.1.3, df must do a sync before doing a
statvfs to get reasonably accurate results.  This can be a real
performance hit.  (I think SVR4 /usr/ucb/df does the sync for no good
reason -- the sync is there only because it was needed on older
BSD-style systems.)  Perhaps the Emacs PROBLEMS section can suggest
that users use GNU fileutils df on older SVR4 and SunOS 4.x hosts, to
avoid that problem on those hosts.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel