Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!hanche
From: hanche@imf.unit.no (Harald Hanche-Olsen)
Newsgroups: comp.sys.apollo
Subject: Re: Peculiar behaviour of "ls //"
Message-ID: <HANCHE.91Jan28175054@hufsa.imf.unit.no>
Date: 28 Jan 91 16:50:54 GMT
References: <JNP.91Jan28150356@tnds05.tele.nokia.fi>
Sender: news@ugle.unit.no
Distribution: comp
Organization: The Norwegian Institute of Technology, Trondheim, Norway.
Lines: 69
In-Reply-To: jnp@tnds05.tele.nokia.fi's message of 28 Jan 91 13:03:56 GMT

In article <JNP.91Jan28150356@tnds05.tele.nokia.fi> jnp@tnds05.tele.nokia.fi (J|rgen N|rgaard) writes:

   Hi,

   [Apollo DN3500, DN2500, SR10.1, SR10.2 BSD4.3, ethernet]

   Can anybody explain why our network directory exhibits a rather strange
   behaviour ?

   What happens is that a command like, say, "ls //" takes rather long time to
   complete whereas "time ls //" is very fast.

   First "ls //":
      bash# date; ls // ; date
      Mon Jan 28 14:34:55 EET 1991
      .bash_history*  .emacs*         andromeda/      dionysos/       kronos/
      .bash_login*    afrodite/       atlas/          kirke/          mjolner/
      Mon Jan 28 14:39:18 EET 1991
      bash#

   That is 5 minutes to complete "ls" (amazing indeed !)

From the output, I can tell that your "ls" is really "ls -F".  The F
flag forces ls to go out and look at each file named, and this can
take some time, particularly if one or more of the nodes whose file
systems are mentioned in // are down.  Since that was apparently not
the case in your example, I would suggest that you may have a network
problem on one of your nodes.

   Next "time ls //":
      bash# time ls //
      .bash_history   .emacs          andromeda       dionysos        kronos
      .bash_login     afrodite        atlas           kirke           mjolner
	      0.5 real         0.0 user         0.1 sys
      bash#

   Which is acceptable.

Now you are really running "ls" without flags.  Then ls only has to
look in the directory file itself to find the file names and print
them, which is fast.

   What is the difference between the two in the first place ?

   And why does it happen at all ? I don't see any clue to this at the
   moment.


   [Further details:
       bash# time ls //atlas
       .cshrc          domain_examples patch           sys5.3          tmp
       bin             etc             rc.local        sysboot         tosi-isode
       .......
	      52.8 real         0.0 user         0.0 sys
       bash#

       bash# time ls //atlas/bsd4.3
       bin     etc     usr
	       0.4 real         0.0 user         0.0 sys
       bash#
   ]

I don't think my theory can explain this one, unless you had any "File
not found" messages in the first listing?

- Harald Hanche-Olsen <hanche@imf.unit.no>
  Division of Mathematical Sciences
  The Norwegian Institute of Technology
  N-7034 Trondheim, NORWAY