Subject: Linux-Development Digest #901
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Sat, 9 Jul 94 10:13:07 EDT

Linux-Development Digest #901, Volume #1          Sat, 9 Jul 94 10:13:07 EDT

Contents:
  Re: How to know the patch level? (Rob Janssen)
  Re: maplay and Lsox for Kernel 1.0.x? (Jeremy Gates)
  Q: a better "last" utility? (Fred Meyer)
  A perplexing riddle (Mike Dowling)
  Re: How to know the patch level (Nils Nieuwejaar)
  Re: TCP/IP programming documentation (Remco Treffkorn)
  Re: <q> kernel tweek for TCP keepalive ?? (Charles Hedrick)
  Kernels and atdisk2 (Jason Zarin)
  Re: Kernels and atdisk2 (Gareth Webber)
  Re: Linux seems to perform terribly for large directories (Rob Janssen)
  Re: List of programs which need shadow changes (Rob Janssen)
  Re: TCP/IP networking for DOSEMU - Why it should be there. (Rob Janssen)
  Re: vmstat for linux? (Rob Janssen)
  Re: Linux Man pages (Rob Janssen)
  1.1.26 breaks dialout serial device (Rene COUGNENC)
  Re: TCP/IP networking for DOSEMU (Luke Howard)
  Re: 1.1.23 - new modules break ftape-1.12c (Jonathan Noel Tombs)
  Re: dual mon support in 1.0.9? (todd j. derr)
  Re: <q> kernel tweek for TCP keepalive ?? (David Kastrup)
  Re: Linux seems to perform terribly for large directories (tpfpdt@eng.ox.ac.uk)
  Re: Linux seems to perform terribly for large directories (Malcolm Beattie)

----------------------------------------------------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: How to know the patch level?
Reply-To: pe1chl@rabo.nl
Date: Fri, 8 Jul 1994 21:43:21 GMT

In <1994Jul8.172831.11600@bnr.ca> yavuz@bnr.ca (Yavuz Onder) writes:

>I want to know what patch level of 1.0 I am running. I tried "uname"
>it only tels me it is "1.0".

Then you have no patches installed.

>Is there a place in source distribution, in header files or
>wherever else, I can extract this info?

It would not be relevant to the binary you are really running...

$ cat /usr/src/linux/tools/version.h
#define UTS_RELEASE "1.1.24"
#define UTS_VERSION "#2 Sat Jul 2 14:33:48 MET DST 1994"
#define LINUX_COMPILE_TIME "14:33:48"
#define LINUX_COMPILE_BY "root"
#define LINUX_COMPILE_HOST "sys3.pe1chl"
#define LINUX_COMPILE_DOMAIN "ampr.org"


Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: jeremy@extro.ucc.su.OZ.AU (Jeremy Gates)
Subject: Re: maplay and Lsox for Kernel 1.0.x?
Date: Fri, 8 Jul 1994 05:32:52 GMT

lpkruger@tucson.Princeton.EDU (Louis P. Kruger) writes:

>In article <1994Jul5.134501.28100@newsserver.rrzn.uni-hannover.de>,
>Friedhelm Kueck <kue@hp1.erib.uni-hannover.de> wrote:
>>Hello world,
>>
>>I tried to compile the maplay-program for playing mpeg-audios under LINUX.
>>As I understand the README, I have also to work with the sox-utility to
>>convert the raw maplay-output to something my SoundBlaster can use. But
>>playing with maplay and sox brings only noise to my ears. I think the
>>problem is, that the Lsox-distribution is patched for the LINUX-sounddriver
>>1.99 - but with kernel 1.0.x came the sound-driver Vers. 2.x and as I read
>>in some READMEs of other sound utilities, Vers. 2.x differs from 1.x.
>>So my question is: where can I find Lsox for sound-driver 2.x?

>It sounds like you have an older version of maplay.  The newest 
>version, 1.2, has built in Linux support.  Your verson of sox will work
>fine, since the sound driver 1.99 was a beta version of 2.0.  Both are
>incompatible with 1.0.

>       - Louis Kruger

I presume Friedhelm used the Linux patch for maplay 1.1, otherwise
he would not have been able to compile. Anyway the trick is, you run

maplay -s file.mpg >foo.sw

play -r 44100 foo.sw

(You see Sox cannot tell the audio type or rate to use).
Which you will probably find still runs a little bit choppy unless you have a
very fast disk. Probably you should convert it to mono.
It would be nice is there was some audio compression system such as MPEG audio
which didn't require so much CPU to decompress. It would be nice too
if anyone has MPEG audio encoder.


Jeremy.

------------------------------

From: frett@downtown.oche.de (Fred Meyer)
Subject: Q: a better "last" utility?
Date: 9 Jul 1994 02:57:51 +0100


Hi!

...i would like to have the "last" utility to provide the information
about the users online-time in hh:mm:ss format instead of hh:mm.
I think this should be possible by decoding the time-field(s) in the
utmp/wtmp-file with more detail.

Maybe somebody on the net can point me to the location of the 
source-code of linux' last-utitlity, please?!?

...please reply via eMail.

TIA,
   Fred
-- 
Fred Meyer                | Phone: + 49-241-4097551
Kapuzinergraben 8         | eMail: frett@downtown.oche.de
52062 Aachen, Germany     |        fred@milenka.ltt.rwth-aachen.de 

------------------------------

From: mike@MooCow.math.nat.tu-bs.de (Mike Dowling)
Subject: A perplexing riddle
Reply-To: on.dowling@zib-berlin.de
Date: Fri, 8 Jul 1994 15:44:29 GMT

I have no idea even what the possible culprit for the following, strange
behaviour on two Linux machines.  I first noticed it with Linux-1.1.24.  I've
just compiled Linux-1.1.26 with the same result.  I've also tried it out on
Linux-1.0.9, and again, the mysterious behaviour is still there.

Here's  one example:

$ file .inputrc
Segmentation fault
$ cp .inputrc ssss
$ file ssss
ascii text
$ cp .inputrc tmp/
$ file tmp/.inputrc
ascii text
$ mv tmp/.inputrc .
$ file .inputrc
Segmentation error

That is with bash-1.14.1

With bash-1.14.0 I get the exact same behaviour.  

With bash-1.13.5 and emacs shell mode there's no problem!

With the csh:

> file .input
.inputrc: ascii text

It's beginning to look like a bash bug, but with the ksh I get
$ file .inputrc
%1      288 Memory fault        file .inputrc


That looks like a Linux error.  With HP-UX the exact same .inputrc works fine
with bash-1.14.1.


At add frustration to misery, the pager "most" is also choosy about the files
it will page.  For example, I can page the latest bash patch, I can always page
standard input, it functions brilliantly as the man-page pager, but won't page
.inputrc.  I just get a blank screen with the cursor at the upper left hand
corner.  At first glance the two problems might look related as both occur with
.inputrc.  Yet a German text of mine also won't page with most, yet file yields

1.text: data

Strangely, too, the most problem seems to be independent of the shell!

Does anyone have any ideas as to what might be going on?
--
                        Mike Dowling

------------------------------

From: nils@cs.dartmouth.edu (Nils Nieuwejaar)
Subject: Re: How to know the patch level
Date: 09 Jul 1994 00:47:45 GMT

In article <1994Jul8.210749.15939@bnr.ca> yavuz@bnr.ca (Yavuz Onder) writes:

   I want to know what patch level of 1.0 I am running. I tried "uname"
   it only tels me it is "1.0".

   Is there a place in source distribution, in header files or
   wherever else, I can extract this info?

It is right at the top of /usr/src/linux/Makefile.

------------------------------

From: remco@emc.rvt.com (Remco Treffkorn)
Subject: Re: TCP/IP programming documentation
Date: Sat, 9 Jul 1994 05:19:05 GMT
Reply-To: remco@emc.rvt.com

Tim Smith (tcsmith@csi.nb.ca) wrote:
: Can someone suggest a good place to look for documentation on tcp/ip 
: programmin under linux.( or Berkley sockets ). Some simple sample source would 
: also suffice. 

The best book I found:

  Prentice Hall
  Internetworking with TCP/IP Volume III
  BSD Socket Version
  Douglas E. Comer / David L. Stevens
  ISBN 0-13-474222-2

  About $50.00 (Oops!)

Maybe you can find it at the library.
It has *lots* of examples.

Remco
-- 

Remco Treffkorn, DC2XT
remco@emc.rvt.com
(408) 685-1201

------------------------------

From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Subject: Re: <q> kernel tweek for TCP keepalive ??
Date: 8 Jul 94 15:41:05 GMT

bass@cais.cais.com (Tim Bass (Network Systems Engineer)) writes:

>It seems that when I telnet, ftp, http, etc. to my linux box
>over a very congested network, many times it just hangs in the middle
>of a session.

>Is is possible that the Linux TCP configuration is not doing KEEPALIVE
>'correctly enough' :-) or does the TCP sockets have a problem with
>KEEPALIVE or ??????

Keepalive is not relevant.  Keepalive occurs only when the connection
is idle, i.e. no data is waiting to be sent.  It consists of a packet
whose header is intentionally illegal.  The goal is to force the other
end to respond, so you know whether it's still up.  That way you can
close the connection if it's not.  If keepalive isn't working, the
only symptom would be that connections would remain open if you take
down the machine on the other end.

If there's a problem with congested networks, it's presumably in
retransmission.  The problem could be on either end.  Some
implementations seem to have debugged with Berkeley TCP/IP.  So if you
do things differently but still within the spec, they don't always
work.  This is particularly the case with some PC implementations.

------------------------------

From: jzarin@nyx10.cs.du.edu (Jason Zarin)
Subject: Kernels and atdisk2
Date: 7 Jul 1994 20:25:13 -0600


As far as I know, the only way to install linux onto a secondary
controller is to remove the primary controller, install linux, add the
atdisk2 patch, recompile the kernel, and then plug the other
controller back in.

Are there any plans to add secondary drive controller support into
the kernel?  It sure would make life a lot easier.  Support for
practically everything else is built-in!

The fact that linux doesn't natively support more than one controller
has always struck me as an oversight.

-- 
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::      Jason Zarin     :: zarin@econ.sscnet.ucla.edu                      ::
:: Grad Student at UCLA :: "To an economist, real life is a special case." ::
::::::::::::::::finger jzarin@nyx.cs.du.edu for PGP public key:::::::::::::::

------------------------------

From: g@clio.demon.co.uk (Gareth Webber)
Subject: Re: Kernels and atdisk2
Date: Fri, 8 Jul 1994 12:07:31 GMT

Jason Zarin (jzarin@nyx10.cs.du.edu) wrote:
[stuff deleted]

: The fact that linux doesn't natively support more than one controller
: has always struck me as an oversight.
[sig removed]

Here here. Linus any chance of adding it in and while you're at it the
ide performance pathes (not with the funny interrupt thingy though).

gary...

-- 
Gareth Webber,                                          g@clio.demon.co.uk
Trinity Hall,                                           gpw1000@cus.cam.ac.uk
Cambridge.                                              gary@royle.org

                        "Ne te confudant illegitimi"

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Linux seems to perform terribly for large directories
Reply-To: pe1chl@rabo.nl
Date: Sat, 9 Jul 1994 08:36:57 GMT

In <1994Jul5.090612.139@dutch.eng.ox.ac.uk> tpfpdt@eng.ox.ac.uk writes:

>In article <1994Jul4.125959.3740@black.ox.ac.uk> mbeattie@black.ox.ac.uk (Malcolm Beattie) writes:
>>In article <1994Jul4.111107.335@dutch.eng.ox.ac.uk> tpfpdt@eng.ox.ac.uk writes:
>>>In article <Cs94z0.s9@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>>>>In <Cs76BL.2F2@research.canon.oz.au> luke@research.canon.oz.au (Luke Kendall)
>>>writes:
>>>>>[Slow ls stuff deleted]
>>
>>Are you really and truly sure that you're not using something like
>>the colour ls or ls -F under Linux which has to stat every single
>>file to find its type? Just another thought...

>Good point.  Yes, ls is much faster than ls -F.  Does this mean that file
>type data is not cached along with the filename?  Maybe it should be, I find
>the -F flag really useful.

File type data is not *stored* along with the filename.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: List of programs which need shadow changes
Reply-To: pe1chl@rabo.nl
Date: Sat, 9 Jul 1994 08:44:22 GMT

In <DHOLLAND.94Jul8151950@scws9.harvard.edu> dholland@scws9.harvard.edu (David Holland) writes:


>jfh@rpp386's message of Thu, 7 Jul 1994 02:55:50 GMT said:

> > >login
> > >telnetd
> > >ftpd     { both the bsd and wu versions }
> > >pop2d
> > >pop3d    -- slackware calls/called this popd
> > >pppd
> > >xlogin
> > 
> > You also need to change rexecd, not that you will want to ever use it ...

>Why not come up with a standardized library interface, fix these
>programs once and for all, and use replacement dynamic libraries to
>get shadow passwords, Kerberos, s/key, and/or whatever other schemes
>come down the pipe?

Hmmm...  that was tried some time ago.  It was promised it would not break
anything, but there were severe performance problems and it also caused other
nasty problems.  (e.g. it left a file open which could cause problems in
programs that expected to be able to open new stdin/stdout/stderr files)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: TCP/IP networking for DOSEMU - Why it should be there.
Reply-To: pe1chl@rabo.nl
Date: Sat, 9 Jul 1994 08:46:05 GMT

In <2vka4u$gkn@blackbird.db.erau.edu> andersoa@news.db.erau.edu (Andrew Anderson) writes:

>James B. MacLean (jmaclean@fox.nstn.ns.ca) wrote:
>:   I know I've been doing a poor job of tantalizing anyone into taking 
>: anything on with this :-(, but Johannes, I'd really appreciate the 
>: interface, even just to say that YES DOSEMU supports TCP/IP over the 
>: pktdrvr. Jason, Rob and Tim Bird have blown the useablity of DOSEMU wide 
>: open with an interface to NetWare. Now I'm interested in getting full-true 
>: pktdriver compatibility.

>Just an idea here -- a friend said that he was able to get multiple 
>logins to a Netware server by loading the ODI drivers *only* before
>starting windows, and then loading VLM's under a different DOS session
>under windows.  This was using only one e-net card.

>Could this be done under linux?  I've tried using the VLM's, but I
>haven't had any luck.  Has anyone else tried this?

If you have the resources for it, please do anything you can to find out
what differentiates the sessions to Netware.
I would certainly want to add the necessary support (if needed or necessary)
to the packet driver, but I lack the info about what to do.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: vmstat for linux?
Reply-To: pe1chl@rabo.nl
Date: Sat, 9 Jul 1994 08:47:14 GMT

In <2vkcji$fv7@darkstar.UCSC.EDU> davis@cats.ucsc.edu (Andrew Preston Davis) writes:


>      I am not sure where to continue looking..so if anyone outthere
>knows where to find a vmstat or related usage type program for linux
>I would be very appreciative.  If none exists and no one is working on it...
>i guess I'd best get hacking :-).

You could try "procinfo".  Not sure it does all you want.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

Crossposted-To: comp.os.linux.misc
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Linux Man pages
Reply-To: pe1chl@rabo.nl
Date: Sat, 9 Jul 1994 08:48:07 GMT

In <2vkdon$jro@thecourier.cims.nyu.edu> monrose@wilma.cs.nyu.edu (Newman Monrose) writes:

>Hi,
>       I'm looking for some of the man pages for Linux. Is there
>any repository site where I might find them ? My installation seems
>to be missing some of them . For example, I need the man page for mprotect() on
>linux to see if the directives are any different from those on 
>SunOs, but I can't seem to find that manpage anywhere.

New manpages were announced just this week.  Please read before posting :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: cougnenc@blaise.ibp.fr (Rene COUGNENC)
Subject: 1.1.26 breaks dialout serial device
Date: 9 Jul 1994 12:26:03 GMT


Serial devices seems broken in 1.1.26; some programs can't open the
dialout device (chat, echo, cat for exemple):

renux:/home/rene/dip $ echo "foo" > /dev/modem
/dev/modem: Appel systhme interrompu

The message is "interrupted system call"; this is when I abort with
CNTRL-C, otherwise the open blocks forever.

Everything was fine with previous patchlevels.
 

------------------------------

From: lukeh@zola.apana.org.au (Luke Howard)
Subject: Re: TCP/IP networking for DOSEMU
Date: 9 Jul 1994 14:04:43 +1000

Richard M. Warner (rick@sjsumcs.sjsu.edu) wrote:
: Unfortunately, it is also false (in part).  Because Netware can run
: over IP (Netware/IP) and in that configuration you can still run
: Netware and 'regular' TCP/IP on a single NIC; with this 
: configuration I could, in a multitasking environment (e.g., DV/X),

Considering that TCP/IP under dosemu is only likely to be used for 
clients (whoops, kinda rules out SOSS + NetWare doesn't it) then couldn't 
Linux assign a range of port numbers to the dosemu session?

Or, given that PKTMUX lets me have a number of DOS clients work at the 
same time, couldn't something similar occur? Don't ask me how it works...



-- 

                      Luke Howard, Luke.Howard@apana.org.au
                   URL http://zola.apana.org.au/0/zola/people
                                Utilisez Linux!!!

------------------------------

From: jon@obelix.cica.es (Jonathan Noel Tombs)
Subject: Re: 1.1.23 - new modules break ftape-1.12c
Date: 7 Jul 1994 10:41:37 +0200

In article <prang.772888846@du9ds4>, >

>1.1.23 my floppystreamer was totally inaccessible with ftape-1.12c.

the patches were added for ftape.

>What I did (after applying the patches and disabling the #define FDC_FIFO_UNTESTED,
>as suggested by those person ("bbroad") who brought in the patches - no go)
>was simply replacing floppy.c with the version from my 1.1.22 kernel and
>everything is fine again.
>
>I hope that this will only be a temporary workaround until the new driver is
>stable again, as the floppy driver is really important in many points of view.

get ftape-1.13b it works fine, and also supports the fc-10 tape controller
the extra speed is noticable :-)

Jon







------------------------------

From: infidel+@pitt.edu (todd j. derr)
Subject: Re: dual mon support in 1.0.9?
Date: 9 Jul 1994 13:16:22 GMT

In article <2vj0cr$pvu@usenet.srv.cis.pitt.edu>, I said:

>hrm.  I had worked on the dual-mon patches way back when....  Jeff
>Grills ended up taking them over from whomever was doing them before,
>and my mono monitor blew up, so I haven't touched them in a while.
>
>however, Jeff no longer runs Linux, and I can get a mono monitor cheap,
>so... I'll get in touch with Jeff, work the patches into 1.1.x, and
>become the active maintainer of them.  Sound good to everyone?

well, I talked with Jeff, got the patches, and hacked them into 1.1.26.
I still have to figure out how to handle the SIGWINCHing if your screens
are different sizes (there used to be a nice way to do it, but I'll have
to go over the new tty stuff some more to figure out how to do it
_now_).  I also need to go pick up a mono-monitor so I can actually
test the things, but it looks ok to me (i.e. it compiles and the code
looks viable :-)...

anyways, I probably will want to test them some before making them
generally available, but if you want what I have so far, email me.

BTW, I'm wondering if I should also make 1.0.x versions... problem being
I don't have a 1.0 kernel anywhere and don't really have the disk to
keep two source trees... so, if you want 'em, you're probably stuck
upgrading to at least 1.1.14 (or whenever the newtty code was put in),
doing it yourself, or buying me a new disk :-)

todd.

------------------------------

From: dak@tschil.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: <q> kernel tweek for TCP keepalive ??
Date: 9 Jul 1994 07:19:45 GMT

bass@cais.cais.com (Tim Bass (Network Systems Engineer)) writes:

>It seems that when I telnet, ftp, http, etc. to my linux box
>over a very congested network, many times it just hangs in the middle
>of a session.  This does not seem to be the case when doing the
>same thing back to an HP-UX box on the same subnet. (but still
>across the same congested router domains)

>Is is possible that the Linux TCP configuration is not doing KEEPALIVE
>'correctly enough' :-) or does the TCP sockets have a problem with
>KEEPALIVE or ??????

As far as I remember, keepalive packets are explicitly forbidden in
the TCP specification. This is because they lead to less
correctly transferred data (if a keepalive fails, and an error is produced)
while causing more network load. Even snowballing effects could occur.

Another question would be whether Linux adheres correctly to the
complete retry characteristics a TCP system should have. Ask that.

Especially, the system should guess a mean transfer time of a link,
and its standard deviation, and do retries using exponential backoff.
Non-arriving packets must not influence the estimation parameters.
See the TCP specs for more. This should (theoretically) cause
performance to be about as good as could be expected at least
network congestion.

I do not know how much is (correctly?) implemented.
-- 
 David Kastrup        dak@pool.informatik.rwth-aachen.de          
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

------------------------------

From: tpfpdt@eng.ox.ac.uk
Subject: Re: Linux seems to perform terribly for large directories
Date: Mon, 4 Jul 1994 11:11:07 GMT

In article <Cs94z0.s9@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>In <Cs76BL.2F2@research.canon.oz.au> luke@research.canon.oz.au (Luke Kendall)
writes:
>>[Slow ls stuff deleted]
>The directory is accessed only with linear seaches.  So, when it is
>large, it becomes exceedingly slow to access it.
>Another factor is that removing files only frees their slots, but does
>not compact the directory.  So, after that it remains as slow as it was
>until you remove and re-create the directory.
>
>The same effect is seen with DOS and with other UNIXes.  Did you compare
>the performance of other UNIX systems on the same hardware?
>Maybe the efficiency of the search can be improved...

No, Linux is definitely slower (at least, pl14 is---time for an upgrade).
Compared to Irix 4, even 2000 files in a directory takes 30secs on a
486/66.  On the Sgi it only takes a few secs.

Still, have you noticed that ftp on linux deals with directories this size,
but the Irix ftp crashes with 'mget *' :-)

Paul.
--
Paul.Thomas@eng.ox.ac.uk


>Rob
>-- 
>-------------------------------------------------------------------------
>| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
>| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
>-------------------------------------------------------------------------



------------------------------

From: mbeattie@black.ox.ac.uk (Malcolm Beattie)
Subject: Re: Linux seems to perform terribly for large directories
Date: Mon, 4 Jul 1994 12:59:59 GMT

In article <1994Jul4.111107.335@dutch.eng.ox.ac.uk> tpfpdt@eng.ox.ac.uk writes:
>In article <Cs94z0.s9@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>>In <Cs76BL.2F2@research.canon.oz.au> luke@research.canon.oz.au (Luke Kendall)
>writes:
>>>[Slow ls stuff deleted]
>>The directory is accessed only with linear seaches.  So, when it is
>>large, it becomes exceedingly slow to access it.
>>Another factor is that removing files only frees their slots, but does
>>not compact the directory.  So, after that it remains as slow as it was
>>until you remove and re-create the directory.
>>
>>The same effect is seen with DOS and with other UNIXes.  Did you compare
>>the performance of other UNIX systems on the same hardware?
>>Maybe the efficiency of the search can be improved...
>
>No, Linux is definitely slower (at least, pl14 is---time for an upgrade).
>Compared to Irix 4, even 2000 files in a directory takes 30secs on a
>486/66.  On the Sgi it only takes a few secs.

Are you really and truly sure that you're not using something like
the colour ls or ls -F under Linux which has to stat every single
file to find its type? Just another thought...

--Malcolm

-- 
Malcolm Beattie <mbeattie@black.ox.ac.uk>
Oxford University Computing Services
Forthcoming change of address: will be <mbeattie@sable.ox.ac.uk> (but not yet).
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
