steiny@hpcupt1.HP.COM (Don Steiny) (12/03/88)
/ hpcupt1:comp.unix.questions / reeder@ut-emx.UUCP (William P. Reeder) / 3:26 pm Nov 30, 1988 / In article <838@nih-csl.UUCP>, ted@nih-csl.UUCP (ted persky) writes: >> it seems that, even for long directory listings, the command takes a very short >> amount of time to complete, considering all the file opening and closing I guess >My experience has been that ls can take a very long time to run on >large directories. Several posters have already explained that ls >doesn't have to open each file in the directory; To display the user name, it needs to map the uid to the name in the /etc/passwd file. On systems with many users this can take a long time.
rwd@bu-cs.BU.EDU (Bob Deroy) (12/04/88)
In article <6060018@hpcupt1.HP.COM> steiny@hpcupt1.HP.COM (Don Steiny) writes: >/ hpcupt1:comp.unix.questions / reeder@ut-emx.UUCP (William P. Reeder) / 3:26 pm Nov 30, 1988 / >In article <838@nih-csl.UUCP>, ted@nih-csl.UUCP (ted persky) writes: >>> it seems that, even for long directory listings, the command takes a very short >>> amount of time to complete, considering all the file opening and closing I guess > >>My experience has been that ls can take a very long time to run on >>large directories. Several posters have already explained that ls >>doesn't have to open each file in the directory; > > To display the user name, it needs to map the uid to the name >in the /etc/passwd file. On systems with many users this can take >a long time. This really annoyed me, so I wrote a small program that reads a directory and hashes the passwd file. It runs a good deal faster than ls -l. It's not fancy and I use ls most of the time, but it does come in handy at times for those directories many users write to. If you would like to see the hashing code, mail me and I will send it to you. -- UUCP: ...!harvard!bu-cs!bu-it!rwd INTERNET: rwd@bu-it.bu.edu CSNET: rwd%bu-it@bu-cs BITNET: engbd3c@buacca
SIMSN%NUSDISCS.BITNET@cunyvm.cuny.edu (11/23/89)
What could be the possible reasons that cause ls -l to be slow, i.e. one line at a time at 1 sec interval? Thanks. > Sim Ser Ngarn (Jnet%"SIMSN@NUSDISCS") > National University of Singapore > Department of Information Systems and Computer Science
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/24/89)
In article <21519@adm.BRL.MIL> SIMSN%NUSDISCS.BITNET@cunyvm.cuny.edu writes: > What could be the possible reasons that cause ls -l > to be slow, i.e. one line at a time at 1 sec interval? Having to look up user names to match the UIDs reported by stat(). This is typically done by a sequential scan of /etc/passwd for EACH name. If you have a large /etc/passwd it can be quite painful. Better solutions have been implemented but I don't think we need to discuss them in this newsgroup.
net@tub.UUCP (Oliver Laumann) (11/25/89)
In article <21519@adm.BRL.MIL> SIMSN%NUSDISCS.BITNET@cunyvm.cuny.edu writes: > > What could be the possible reasons that cause ls -l > to be slow, i.e. one line at a time at 1 sec interval? Possible reason #1: You are running SunOS and the YP-server is broken. I have observed this behaviour several times on our Suns. Try `ypcat passwd' or something like that to find out what's wrong. Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP
scm@dlcq15.datlog.co.uk (Steve Mawer) (12/01/89)
In article <21519@adm.BRL.MIL> SIMSN%NUSDISCS.BITNET@cunyvm.cuny.edu writes: > What could be the possible reasons that cause ls -l > to be slow, i.e. one line at a time at 1 sec interval? On AIX (spit!) I've found that this happens when the user and/or group IDs don't exist in the password and/or group files. With lots of entries in the password file it takes a looooooong time to not find a name. You can tell if this is your problem by checking the `ls' output - are there user names or numbers against the files? If numbers, change the owner and/or group as necessary to an existing one. This may (or may not) occur on other systems, I've not noticed it on Ultrix or Xenix, but I could have just been lucky :-). Hope this helps. -- Steve C. Mawer <scm@datlog.co.uk> or < {backbone}!ukc!datlog!scm > Voice: +44 1 863 0383 (x2153)
randy@chinet.chi.il.us (Randy Suess) (12/09/89)
In article <1989Dec1.093729.20250@dlcq15.datlog.co.uk> scm@dlcq15.datlog.co.uk (Steve Mawer) writes: ]In article <21519@adm.BRL.MIL> SIMSN%NUSDISCS.BITNET@cunyvm.cuny.edu writes: ]> What could be the possible reasons that cause ls -l ]> to be slow, i.e. one line at a time at 1 sec interval? ]On AIX (spit!) I've found that this happens when the user and/or group IDs ]don't exist in the password and/or group files. With lots of entries in ]the password file it takes a looooooong time to not find a name. Another possibility is that you have a large /etc/passwd file. ls -l looks up the name and group for the actual uid and gid. This gets real slow. To find out if this is the case, use ls -n. This will just print out the numeric uid/gid without the passwd lookup. It should be a lot faster if this is the problem. -randy -- Randy Suess randy@chinet.chi.il.us
guy@auspex.auspex.com (Guy Harris) (12/09/89)
>> What could be the possible reasons that cause ls -l >> to be slow, i.e. one line at a time at 1 sec interval? > >On AIX (spit!) I've found that this happens when the user and/or group IDs >don't exist in the password and/or group files. With lots of entries in >the password file it takes a looooooong time to not find a name. ... >This may (or may not) occur on other systems, I've not noticed it on Ultrix >or Xenix, but I could have just been lucky :-). It depends on how your system accesses the password database, and how big "/etc/passwd" is if your system accesses the password database by scanning it linearly. If your system has a small password file, or it uses a 4.3BSD-style "(n)dbm" database built from it, or it has some network server (e.g., Yellow Pages, Apollo Registry, Hesiod), it may not be so slow since either 1) the linear search is quick or 2) the linear search isn't necessary.