jnp@tnds05.tele.nokia.fi (J|rgen N|rgaard) (01/28/91)
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 !)
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.
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#
]
--
ORIGIN '~jnp/stdDisclaimers';
[[--- Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) |
| e-mail: jnp@tele.nokia.fi || Telephone: <..>-358-0-511-5671 |
| mail: Nokia Telecommunications, PL 33, SF-02601 Espoo Finland ---]]hanche@imf.unit.no (Harald Hanche-Olsen) (01/29/91)
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, NORWAYvinoski@apollo.HP.COM (Stephen Vinoski) (01/29/91)
In article <JNP.91Jan28150356@tnds05.tele.nokia.fi> jnp@tnds05.tele.nokia.fi (J|rgen N|rgaard) writes: >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 !) > >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# It looks like your "ls" is an alias for "ls -F" which results in a stat() for every entry to be listed. When you run it via the "time" command, the alias is not used. -steve | Steve Vinoski (508)256-6600 x5904 | Internet: vinoski@apollo.hp.com | | Testability and Diagnostics | UUCP: ...mit-eddie!apollo!vinoski| | HP Apollo Division, Chelmsford, MA 01824 | ...uw-beaver!apollo!vinoski|
bep@quintro.uucp (Bryan Province) (01/30/91)
In article <4f7aa1e7.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes: >In article <JNP.91Jan28150356@tnds05.tele.nokia.fi> jnp@tnds05.tele.nokia.fi (J|rgen N|rgaard) writes: >>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 !) >> >>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# > >It looks like your "ls" is an alias for "ls -F" which results in a stat() for >every entry to be listed. When you run it via the "time" command, the alias is >not used. > >-steve As a side point, I don't think that the "//" is the proper place to store files such as .emacs, .bash_login, and .bash_history. I always thought of this directory as being reserved for storing the cataloged names of nodes in the network. You might try removing these files and see what happens although I don't think that's why it takes so long to do an ls -F. You might also try the following command: time ls -F // to see if it also takes 5 minutes. -- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- Bryan Province -Glenayre Corp., Quincy, IL- quintro!bep@lll-winken.llnl.gov "I tried putting instant coffee in the microwave, I almost went back in time." - Steven Wright