Re: ls -l takes a forever to finish.
This issue has been resolved. Thanks for your assistance everyone. Changing /etc/nsswitch.conf from passwd: compat to read passwd: files resolved the issue. Thanks Mark - Original Message - From: cpghost [EMAIL PROTECTED] To: Mark Evans [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, December 13, 2007 12:22 PM Subject: Re: ls -l takes a forever to finish. On Wed, 12 Dec 2007 13:28:23 -0600 Mark Evans [EMAIL PROTECTED] wrote: this program seems to have the same issues with it. [Please don't top post.] Of course, if ls -lf has those issues, sortls.py will have them too, because it just runs it and sorts its output externally with another sorting algorithm. sortls.py speeds up ls -l considerably for huge (10,000+ entries) directories by using another sorting algorithm, it doesn't do anything else. Just to ask again: while you're waiting for ls -lf, what does top say? Is that process accumulating CPU time, or is it just sitting around waiting, waiting, waiting...? Are you using NFS or another file system where stat(2) is expensive? Thanks Mark - Original Message - From: cpghost [EMAIL PROTECTED] To: Bill Moran [EMAIL PROTECTED] Cc: Wojciech Puchar [EMAIL PROTECTED]; [EMAIL PROTECTED]; Mark Evans [EMAIL PROTECTED] Sent: Thursday, November 29, 2007 8:42 AM Subject: Re: ls -l takes a forever to finish. On Thu, 29 Nov 2007 08:42:44 -0500 Bill Moran [EMAIL PROTECTED] wrote: In response to Wojciech Puchar [EMAIL PROTECTED]: ls | wc strange. i did [EMAIL PROTECTED] ~/b]$ a=0;while [ $a -lt 1 ];do mkdir $a;a=$[a+1];done completed 25 seconds on 1Ghz CPU ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. Another possible scenario is that the directory is badly fragmented. Unless something has changed since I last researched this (which is possible) FreeBSD doesn't manage directory fragmentation during use. If you're constantly adding and removing files, it's possible that the directory entry is such a mess that it takes ls a long time to process it. Yes, that's also possible. But sorting is really the culprit here: it *is* possible to create a directory with filenames in such a way that it triggers Quicksort's O(N^2) worst case instead of O(N log N). The following Python (2.5) program calls ls -lf and sorts its output with Python's own stable sort() routine (which is NOT qsort(3)). On a directory with 44,000 entries, it runs orders of magnitude faster than ls -l, even though it has to use the decorate-sort-undecorate idiom to sort the output according according the filename, and it is interpreted rather than compiled! I guess that replacing qsort(3) in /usr/src/lib/libc/gen/fts.c:fts_sort() with another sort algorithm which doesn't expose this anomaly would solve that problem. - cut here -- cut here #!/usr/bin/env python # sortls.py -- sort output of ls -lf with python's stable sort routine. import os def sort_ls_lf(path): Sort the output of ls -lf path os.chdir(path) lines = os.popen(ls -lf, r).readlines() dsu = [ (line.split()[-1], line) for line in lines ] dsu.sort() return ''.join(tupl[1] for tupl in dsu) if __name__ == '__main__': import sys if len(sys.argv) 2: print sys.stderr, Usage:, sys.argv[0], path sys.exit(1) path = sys.argv[1] try: print sort_ls_lf(path) except IOError: pass # silently absorb broken pipe and other errors - cut here -- cut here -cpghost. -- Cordula's Web. http://www.cordula.ws/ -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
On Wed, 12 Dec 2007 13:28:23 -0600 Mark Evans [EMAIL PROTECTED] wrote: this program seems to have the same issues with it. [Please don't top post.] Of course, if ls -lf has those issues, sortls.py will have them too, because it just runs it and sorts its output externally with another sorting algorithm. sortls.py speeds up ls -l considerably for huge (10,000+ entries) directories by using another sorting algorithm, it doesn't do anything else. Just to ask again: while you're waiting for ls -lf, what does top say? Is that process accumulating CPU time, or is it just sitting around waiting, waiting, waiting...? Are you using NFS or another file system where stat(2) is expensive? Thanks Mark - Original Message - From: cpghost [EMAIL PROTECTED] To: Bill Moran [EMAIL PROTECTED] Cc: Wojciech Puchar [EMAIL PROTECTED]; [EMAIL PROTECTED]; Mark Evans [EMAIL PROTECTED] Sent: Thursday, November 29, 2007 8:42 AM Subject: Re: ls -l takes a forever to finish. On Thu, 29 Nov 2007 08:42:44 -0500 Bill Moran [EMAIL PROTECTED] wrote: In response to Wojciech Puchar [EMAIL PROTECTED]: ls | wc strange. i did [EMAIL PROTECTED] ~/b]$ a=0;while [ $a -lt 1 ];do mkdir $a;a=$[a+1];done completed 25 seconds on 1Ghz CPU ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. Another possible scenario is that the directory is badly fragmented. Unless something has changed since I last researched this (which is possible) FreeBSD doesn't manage directory fragmentation during use. If you're constantly adding and removing files, it's possible that the directory entry is such a mess that it takes ls a long time to process it. Yes, that's also possible. But sorting is really the culprit here: it *is* possible to create a directory with filenames in such a way that it triggers Quicksort's O(N^2) worst case instead of O(N log N). The following Python (2.5) program calls ls -lf and sorts its output with Python's own stable sort() routine (which is NOT qsort(3)). On a directory with 44,000 entries, it runs orders of magnitude faster than ls -l, even though it has to use the decorate-sort-undecorate idiom to sort the output according according the filename, and it is interpreted rather than compiled! I guess that replacing qsort(3) in /usr/src/lib/libc/gen/fts.c:fts_sort() with another sort algorithm which doesn't expose this anomaly would solve that problem. - cut here -- cut here #!/usr/bin/env python # sortls.py -- sort output of ls -lf with python's stable sort routine. import os def sort_ls_lf(path): Sort the output of ls -lf path os.chdir(path) lines = os.popen(ls -lf, r).readlines() dsu = [ (line.split()[-1], line) for line in lines ] dsu.sort() return ''.join(tupl[1] for tupl in dsu) if __name__ == '__main__': import sys if len(sys.argv) 2: print sys.stderr, Usage:, sys.argv[0], path sys.exit(1) path = sys.argv[1] try: print sort_ls_lf(path) except IOError: pass # silently absorb broken pipe and other errors - cut here -- cut here -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
this program seems to have the same issues with it. Thanks Mark - Original Message - From: cpghost [EMAIL PROTECTED] To: Bill Moran [EMAIL PROTECTED] Cc: Wojciech Puchar [EMAIL PROTECTED]; [EMAIL PROTECTED]; Mark Evans [EMAIL PROTECTED] Sent: Thursday, November 29, 2007 8:42 AM Subject: Re: ls -l takes a forever to finish. On Thu, 29 Nov 2007 08:42:44 -0500 Bill Moran [EMAIL PROTECTED] wrote: In response to Wojciech Puchar [EMAIL PROTECTED]: ls | wc strange. i did [EMAIL PROTECTED] ~/b]$ a=0;while [ $a -lt 1 ];do mkdir $a;a=$[a+1];done completed 25 seconds on 1Ghz CPU ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. Another possible scenario is that the directory is badly fragmented. Unless something has changed since I last researched this (which is possible) FreeBSD doesn't manage directory fragmentation during use. If you're constantly adding and removing files, it's possible that the directory entry is such a mess that it takes ls a long time to process it. Yes, that's also possible. But sorting is really the culprit here: it *is* possible to create a directory with filenames in such a way that it triggers Quicksort's O(N^2) worst case instead of O(N log N). The following Python (2.5) program calls ls -lf and sorts its output with Python's own stable sort() routine (which is NOT qsort(3)). On a directory with 44,000 entries, it runs orders of magnitude faster than ls -l, even though it has to use the decorate-sort-undecorate idiom to sort the output according according the filename, and it is interpreted rather than compiled! I guess that replacing qsort(3) in /usr/src/lib/libc/gen/fts.c:fts_sort() with another sort algorithm which doesn't expose this anomaly would solve that problem. - cut here -- cut here #!/usr/bin/env python # sortls.py -- sort output of ls -lf with python's stable sort routine. import os def sort_ls_lf(path): Sort the output of ls -lf path os.chdir(path) lines = os.popen(ls -lf, r).readlines() dsu = [ (line.split()[-1], line) for line in lines ] dsu.sort() return ''.join(tupl[1] for tupl in dsu) if __name__ == '__main__': import sys if len(sys.argv) 2: print sys.stderr, Usage:, sys.argv[0], path sys.exit(1) path = sys.argv[1] try: print sort_ls_lf(path) except IOError: pass # silently absorb broken pipe and other errors - cut here -- cut here Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish
On Fri, Nov 30, 2007 at 05:49 , [EMAIL PROTECTED] moved his mouse, rebooted for the change to take effect, and then said: Date: Thu, 29 Nov 2007 08:42:44 -0500 From: Bill Moran [EMAIL PROTECTED] Subject: Re: ls -l takes a forever to finish. In response to Wojciech Puchar [EMAIL PROTECTED]: ls | wc strange. i did [EMAIL PROTECTED] ~/b]$ a=0;while [ $a -lt 1 ];do mkdir $a;a=$[a+1];done completed 25 seconds on 1Ghz CPU ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. Another possible scenario is that the directory is badly fragmented. Unless something has changed since I last researched this (which is possible) FreeBSD doesn't manage directory fragmentation during use. If you're constantly adding and removing files, it's possible that the directory entry is such a mess that it takes ls a long time to process it. Of course, Wojciech's test won't demonstrate this, as the directory is freshly created, even to the point that the filenames are actually in alpha order in the directory. One method to test this would be to tar up the directory and extract it somewhere else on the machine (assuming you have enough space to do so). If the newly created directory doesn't have the problem, it's likely that the directory entry has become a mess. Use ls -l to compare the sizes of the actual directories themselves as a little exercise. There is a way to recreate the directory tree without having to use up a lot of free space. I used to do this when (in the old days) I was running a news node and some hierarchies would get so so large that directory access would be very slow even after the expire because the directory was so huge. Read the man page for cpio and use the -pdlmv option. This will create a new directory tree using ONLY links, so that you have done nothing except make a directory and have moved NO files at all. Then you can remove all the files in the original directory, returning the link count on each file to 1, and have an optimized directory that has all the files of the original. And if I recall correctly it will act like the tar utility where all the sub-directories will be in the first of each directory, thus reducing search time. I have not used the GNU version of this but used it all the time on SysV based systems I maintained - but it should be the same [however I have noticed that sometimes GNU based things have subtle changes at times]. Anyway, if that turns out to be the problem, you can fix it by taring the directory and then restoring it from the tarfile. Not an ideal solution, mind you. Try the above sometime IF EVERYTHING IS ON THE SAME FILE SYSTEM and prepare to be amazed. It's fast. -- Bill Moran http://www.potentialtech.com Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
Is a partition close to full, use df to see that. doesn't matter as ls read, not writes. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
ls | wc strange. i did [EMAIL PROTECTED] ~/b]$ a=0;while [ $a -lt 1 ];do mkdir $a;a=$[a+1];done completed 25 seconds on 1Ghz CPU ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
Wojciech Puchar wrote: ls | wc strange. i did [EMAIL PROTECTED] ~/b]$ a=0;while [ $a -lt 1 ];do mkdir $a;a=$[a+1];done completed 25 seconds on 1Ghz CPU ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. Has anyone tried fsck and/or smartmontools on the drive? Maybe something like Spinrite? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
In response to Wojciech Puchar [EMAIL PROTECTED]: ls | wc strange. i did [EMAIL PROTECTED] ~/b]$ a=0;while [ $a -lt 1 ];do mkdir $a;a=$[a+1];done completed 25 seconds on 1Ghz CPU ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. Another possible scenario is that the directory is badly fragmented. Unless something has changed since I last researched this (which is possible) FreeBSD doesn't manage directory fragmentation during use. If you're constantly adding and removing files, it's possible that the directory entry is such a mess that it takes ls a long time to process it. Of course, Wojciech's test won't demonstrate this, as the directory is freshly created, even to the point that the filenames are actually in alpha order in the directory. One method to test this would be to tar up the directory and extract it somewhere else on the machine (assuming you have enough space to do so). If the newly created directory doesn't have the problem, it's likely that the directory entry has become a mess. Use ls -l to compare the sizes of the actual directories themselves as a little exercise. Anyway, if that turns out to be the problem, you can fix it by taring the directory and then restoring it from the tarfile. Not an ideal solution, mind you. -- Bill Moran http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
On Thu, 29 Nov 2007 08:42:44 -0500 Bill Moran [EMAIL PROTECTED] wrote: In response to Wojciech Puchar [EMAIL PROTECTED]: ls | wc strange. i did [EMAIL PROTECTED] ~/b]$ a=0;while [ $a -lt 1 ];do mkdir $a;a=$[a+1];done completed 25 seconds on 1Ghz CPU ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. Another possible scenario is that the directory is badly fragmented. Unless something has changed since I last researched this (which is possible) FreeBSD doesn't manage directory fragmentation during use. If you're constantly adding and removing files, it's possible that the directory entry is such a mess that it takes ls a long time to process it. Yes, that's also possible. But sorting is really the culprit here: it *is* possible to create a directory with filenames in such a way that it triggers Quicksort's O(N^2) worst case instead of O(N log N). The following Python (2.5) program calls ls -lf and sorts its output with Python's own stable sort() routine (which is NOT qsort(3)). On a directory with 44,000 entries, it runs orders of magnitude faster than ls -l, even though it has to use the decorate-sort-undecorate idiom to sort the output according according the filename, and it is interpreted rather than compiled! I guess that replacing qsort(3) in /usr/src/lib/libc/gen/fts.c:fts_sort() with another sort algorithm which doesn't expose this anomaly would solve that problem. - cut here -- cut here #!/usr/bin/env python # sortls.py -- sort output of ls -lf with python's stable sort routine. import os def sort_ls_lf(path): Sort the output of ls -lf path os.chdir(path) lines = os.popen(ls -lf, r).readlines() dsu = [ (line.split()[-1], line) for line in lines ] dsu.sort() return ''.join(tupl[1] for tupl in dsu) if __name__ == '__main__': import sys if len(sys.argv) 2: print sys.stderr, Usage:, sys.argv[0], path sys.exit(1) path = sys.argv[1] try: print sort_ls_lf(path) except IOError: pass # silently absorb broken pipe and other errors - cut here -- cut here Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
ls takes 0.1 seconds user time, ls -l takes 0.3 second user time. unless you have 486/33 or slower system there is something wrong. Has anyone tried fsck and/or smartmontools on the drive? Maybe something like Spinrite? he stated that CPU load is near 100% so it's not disk problem ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
unless you have 486/33 or slower system there is something wrong. Another possible scenario is that the directory is badly fragmented. Unless something has changed since I last researched this (which is it is for sure. the fix would be mv /usr/home /usr/oldhome;mkdir /usr/home;mv /usr/oldhome/* /usr/home and after successfull move - rm -rf /usr/home Of course, Wojciech's test won't demonstrate this, as the directory is freshly created, even to the point that the filenames are actually in indeed ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
I guess that replacing qsort(3) in /usr/src/lib/libc/gen/fts.c:fts_sort() with another sort algorithm which doesn't expose this anomaly would solve that problem. for sure his /home wasn't worst case. it's just average case so it's not that problem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
it is for sure. the fix would be mv /usr/home /usr/oldhome;mkdir /usr/home;mv /usr/oldhome/* /usr/home and after successfull move - rm -rf /usr/home I really hope you meant: rm -rf /usr/oldhome Also, mv just moves pointers around, wouldn't a cp -Rp be needed instead? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
the fix would be mv /usr/home /usr/oldhome;mkdir /usr/home;mv /usr/oldhome/* /usr/home and after successfull move - rm -rf /usr/home I like this idea very much... It results in 100% data loss of your /usr/home contents... ;-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
find no aliease for ls -l df returns the following. So looks like there is restill about 40 G on the partition. ilesystem SizeUsed Avail Capacity Mounted on /dev/aacd0s1a 97G 57G 33G64%/ devfs1.0K1.0K 0B 100%/dev devfs1.0K1.0K 0B 100%/var/named/dev Thanks mark - Original Message - From: Brian [EMAIL PROTECTED] To: Mark Evans [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 4:35 PM Subject: Re: ls -l takes a forever to finish. Is a partition close to full, use df to see that. Is ls -l aliased to something else that is digging into your directory tree, like when you're in /usr and type du? brian On Tue, 27 Nov 2007, Mark Evans wrote: I'm using FreeBSD 6.1-RELEASE. When I run ls -l it takes forever for the it to complete. top shows that the ls -l command uses about 98% of the CPU doing the time. If I run ls I do not experience any problem. anyone have any ideas? Thanks Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
No we are not using NIS. it is a large directory i am listing. actually it is the /usr/home directory, and is probably the largest on the system. However ls -l runs for close to six minutesand spends the 10 seconds scrolling the screen with the results. so i wait ls to start showing the results for about 5 and a half minutes. Even on a older and much slower system i've never seen it talk more than 15 seconds to complete. Thanks Mark - Original Message - From: Kris Kennaway [EMAIL PROTECTED] To: Mark Evans [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 5:13 PM Subject: Re: ls -l takes a forever to finish. Mark Evans wrote: I'm using FreeBSD 6.1-RELEASE. When I run ls -l it takes forever for the it to complete. top shows that the ls -l command uses about 98% of the CPU doing the time. If I run ls I do not experience any problem. anyone have any ideas? Are you using NIS for user/group lookups? Is it a large directory that is taking a long time to sort? Kris -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
HOW large is the directory? ls | wc -l On Nov 28, 2007 7:44 AM, Mark Evans [EMAIL PROTECTED] wrote: No we are not using NIS. it is a large directory i am listing. actually it is the /usr/home directory, and is probably the largest on the system. However ls -l runs for close to six minutesand spends the 10 seconds scrolling the screen with the results. so i wait ls to start showing the results for about 5 and a half minutes. Even on a older and much slower system i've never seen it talk more than 15 seconds to complete. Thanks Mark - Original Message - From: Kris Kennaway [EMAIL PROTECTED] To: Mark Evans [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 5:13 PM Subject: Re: ls -l takes a forever to finish. Mark Evans wrote: I'm using FreeBSD 6.1-RELEASE. When I run ls -l it takes forever for the it to complete. top shows that the ls -l command uses about 98% of the CPU doing the time. If I run ls I do not experience any problem. anyone have any ideas? Are you using NIS for user/group lookups? Is it a large directory that is taking a long time to sort? Kris -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
On Wed, 2007-11-28 at 09:44 -0600, Mark Evans wrote: No we are not using NIS. it is a large directory i am listing. actually it is the /usr/home directory, and is probably the largest on the system. However ls -l runs for close to six minutesand spends the 10 seconds scrolling the screen with the results. so i wait ls to start showing the results for about 5 and a half minutes. Even on a older and much slower system i've never seen it talk more than 15 seconds to complete. Thanks Mark How many directories, roughly? I've seen ls take *many* minutes listing the contents of a directory that contained tens of thousands of files. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
ls | wc returns88368836 71583 Thanks Mark - Original Message - From: Jeff Mohler To: Mark Evans Cc: [EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 9:52 AM Subject: Re: ls -l takes a forever to finish. HOW large is the directory? ls | wc -l On Nov 28, 2007 7:44 AM, Mark Evans [EMAIL PROTECTED] wrote: No we are not using NIS. it is a large directory i am listing. actually it is the /usr/home directory, and is probably the largest on the system. However ls -l runs for close to six minutesand spends the 10 seconds scrolling the screen with the results. so i wait ls to start showing the results for about 5 and a half minutes. Even on a older and much slower system i've never seen it talk more than 15 seconds to complete. Thanks Mark - Original Message - From: Kris Kennaway [EMAIL PROTECTED] To: Mark Evans [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 5:13 PM Subject: Re: ls -l takes a forever to finish. Mark Evans wrote: I'm using FreeBSD 6.1-RELEASE. When I run ls -l it takes forever for the it to complete. top shows that the ls -l command uses about 98% of the CPU doing the time. If I run ls I do not experience any problem. anyone have any ideas? Are you using NIS for user/group lookups? Is it a large directory that is taking a long time to sort? Kris -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
On Wed, 28 Nov 2007 09:44:03 -0600 Mark Evans [EMAIL PROTECTED] wrote: No we are not using NIS. it is a large directory i am listing. actually it is the /usr/home directory, and is probably the largest on the system. However ls -l runs for close to six minutesand spends the 10 seconds scrolling the screen with the results. so i wait ls to start showing the results for about 5 and a half minutes. Even on a older and much slower system i've never seen it talk more than 15 seconds to complete. Does it run (much) faster with the -f flag or -lf flags? I have a similar problem with *huge* directories: sorting them is incredibly slow... though -l makes no difference; it's the sorting itself than makes one think it is O(N^2) instead of O(N log N). It could be a pathological case of Quicksort (ls(1) calls fts_open(), which itself calls fts_sort() from /usr/src/lib/libc/gen/fts.c, and that function calls qsort(3); so it's not entirely impossible... -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ls -l takes a forever to finish.
I'm using FreeBSD 6.1-RELEASE. When I run ls -l it takes forever for the it to complete. top shows that the ls -l command uses about 98% of the CPU doing the time. If I run ls I do not experience any problem. anyone have any ideas? Thanks Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
On Nov 27, 2007, at 1:53 PM, Mark Evans wrote: I'm using FreeBSD 6.1-RELEASE. When I run ls -l it takes forever for the it to complete. top shows that the ls -l command uses about 98% of the CPU doing the time. If I run ls I do not experience any problem. anyone have any ideas? Thanks Mark That's incredibly strange because ls is a simple program... Could you attach gdb to ls and find out where it's eating up all of your CPU time? -Garrett ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
Is a partition close to full, use df to see that. Is ls -l aliased to something else that is digging into your directory tree, like when you're in /usr and type du? brian On Tue, 27 Nov 2007, Mark Evans wrote: I'm using FreeBSD 6.1-RELEASE. When I run ls -l it takes forever for the it to complete. top shows that the ls -l command uses about 98% of the CPU doing the time. If I run ls I do not experience any problem. anyone have any ideas? Thanks Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ls -l takes a forever to finish.
Mark Evans wrote: I'm using FreeBSD 6.1-RELEASE. When I run ls -l it takes forever for the it to complete. top shows that the ls -l command uses about 98% of the CPU doing the time. If I run ls I do not experience any problem. anyone have any ideas? Are you using NIS for user/group lookups? Is it a large directory that is taking a long time to sort? Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
