Subject: Linux-Development Digest #916
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:     Fri, 15 Jul 94 08:13:05 EDT

Linux-Development Digest #916, Volume #1         Fri, 15 Jul 94 08:13:05 EDT

Contents:
  Re: aha1542cf only good at 8MHz CPU ?? (Karsten Steffens)
  POP3 server for Linux (1.1.24)? (Pete Kruckenberg)
  Re: Returning free'd memory (Frank Lofaro)
  Need tester with 2.88 MB floppy (Helmut Geyer)
  dlpi support on linux (Luciano Zapparata)
  mstats.o missing in libc.a (H.C.W. Kwok)
  Andrew suddenly kills X (misch@elara.fsag.de)
  Re: 1.1.28: SCSI (Heinz Kranefeld)
  Re: syscall() problem, actual program... (Jim Balter)
  Linux detecting Turtle Beach MAUI incorrectly (Schultz, Russell)
  Re: Linux Performance Enhance ? (Jim Balter)
  Re: Linux Performance Enhance ? (Jim Balter)
  Re: system("ls") doesn't display anything to screen? (Kevin Lentin)
  Re: Linux Performance Enhance ? (Jim Balter)
  Re: Linux Performance Enhance ? (Jim Balter)
  Re: Linux seems to perform terribly for large directories (Jim Balter)

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

From: karsten@kshome.ruhr.de (Karsten Steffens)
Crossposted-To: comp.os.linux.help,comp.periphs.scsi
Subject: Re: aha1542cf only good at 8MHz CPU ??
Date: 13 Jul 1994 11:20:49 GMT

Finally it came out that my V7 Mirage VLB, Bios 5.01, S3-805C, was causing
the trouble with the adaptec 1542cf - and not only that. Just for the 
records: exchanging the V7 with a Cirrus clgd5426 VLB solved the problem: the
adaptec is running pretty fine now at 33MHz CPU-clock as well. And the V7
caused in conjunction with the other stuff another problem, which I already
gave up to track down, because it was not that big: with the V7 installed
I cannot boot from floppy unless the external and internal cache of the 486
are disabled. Booting from harddisk was fine though. That trouble now also
has gone.

Besides the fact that I had to fork out some money to buy the new graphics
card there is another drawback: the picture quality of the V7 was a lot
better than that of the cirrus, although I'm running both at 1024*768 with
70 Hz. The cirrus produces - so to speak - fatter characters; i.e., the picture
is not that sharp as it was with the - admitted - more expensive V7. You
can see that when you for instance mark a block of text under X with the
mouse: the black background makes the inverted letters almost unreadable. 
Sigh... 

Karsten

--
==================>    Dipl.=Phys.Karsten Steffens   <=====================
   karsten@kshome.ruhr.de          |      steffens@ikp.uni-muenster.de
Marl - close to Recklinghausen     |         Institut fuer Kernphysik
  North of the Ruhrgebiet          |   Westf.Wilhelms-Universitaet Muenster

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

From: kruckenb@sal.cs.utah.edu (Pete Kruckenberg)
Crossposted-To: comp.os.linux.admin
Subject: POP3 server for Linux (1.1.24)?
Date: 13 Jul 1994 19:07:17 GMT

I'm trying to get a POP3 server set up on my Linux (1.1.24) box, and
am having some problems. I got the pop3d-1.00.4.tar.gz from sunsite,
and when I try to compile, there are two #include files from util.c it
can't find: shadow/shadow.h and shadow/pwauth.h. These are only
included when SHADOWPWD is defined, which maybe I don't need. I just
want to set up a server people can connect into from their (PC)
workstation or remotely. I don't know what the SHADOWPWD does--maybe
if someone could explain, I might just disable it.

While I'm on the subject, I'd really like to find some good
documentation on what POP can do and how to configure both a client
and a server. Ultimately, I'd like to use POP to provide a high-volume
mailing list over our 28.8k link by using POP to send a single copy of
each out-going message to our provider, where it would be distributed.
That way I would only send one message over our bandwidth, and the 200
or so copies would go out from our provider. Is this possible to do,
and can I do it with a list server such as LISTSERV, MajorDomo, or
others?  Any pointers or suggestions would be appreciated.

Thanks for your help.
Pete.
kruckenb@sal.cs.utah.edu
-- 
  ------------------------------------------------------------------------
  Pete Kruckenberg                       School: kruckenb@sal.cs.utah.edu
  University of Utah                       Work: pete@dswi.com
  Computer Engineering    For even more addresses, "finger pete@dswi.com"

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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: Returning free'd memory
Date: Fri, 15 Jul 94 02:55:33 GMT

In article <304kr8$ain@csnews.cs.Colorado.EDU> drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes:
>In article <CsyA71.8Fo@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>>In <graphix.774209621@spiff.cc.iastate.edu> graphix@iastate.edu (Kent A Vander Velden) writes:
>>
>>>Are there any planed changes to the Linux kernel to actually completely give 
>>>the memory back to the system which was free'd by the program before the 
>>>program exits?
>>
>>There are no changes needed in the Linux kernel for this.  It is a function
>>(not) performed by the C libraries.
>
>This isn't entirely accurate.  While it is definately possible for 
>the user libraries to sbrk() and reduce the size of the data segment,
>you can end up with things like
>
>    a = malloc (20 * 1024 * 1024);
>    b = malloc (16);
>    free(a);
>
>and your program will still be holding down an extra 20M.  In real life,
>this would be starting a bunch of X applications which caused resources 
>to be allocated in the X server which are essentially transient, another
>which stayed on your desktop, and the transient applications terminating
>after the permamant application started.
>
>To deal with the situation optimally, you need to have some 
>amount of malloc()/free() implemented in the kernel although
>you want to avoid system call overhead for Many Small malloc()s.
>
>I'd suggest implementing a general user alloc region(s) / free region(s)
>call in the kernel.
>
>Rather than using sbrk() when more memory was needed, malloc() could 
>use the allocate region(s) call and allocate memory any where in 
>the process's address space.  Depending on the pattern of malloc()s
>detected, it could request a larger hunk than needed to avoid the 
>overhead of multiple calls.
>
>When a memory region was free, malloc would add it to an internal
>list of freed regions, and perhaps after some threshold was reached
>would call the free region(s) function to return the regions to 
>Linux, which would unmap them from address space.
>
>This insures that even if the process's memory space becomes fragmented,
>nothing can force pages to remain allocated.  Unfortunately, it means that
>malloc needs to be implemented differently and that applications which try
>to determine their size or whatever based on the break value may fail.
>
>-- 
>Drew Eckhardt drew@Colorado.EDU
>1970 Landcruiser FJ40 w/350 Chevy power
>1982 Yamaha XV920J Virago

        This is a GREAT idea, one I have been thinking was a great idea for a 
long time. ;)

        As for applications breaking, they can be changed from
depending on old behavior, or use the kernel personality
mechanism. I.E. add a sys_personality(OLD_BRK_SEMANTICS) or whatever
to the code, or having something make such a call before execing the
program.

        I'd hate such a good idea quashed due to backwards
compatibility concerns.  Allowing user processes to give up regions to
the MM ppol would be great in quashing monster X servers and kernel
"Out of memory!" errors due to inability to deallocate memory due to
the limitations of brk()/sbrk().

        How hard would it be to allow such a kernel syscall:
unmap_from_process_memory_space(begin_addr, end_addr)

or something similar. What about mprotect() while we are at it?

        I've been thinking of hacking on both, but I don't know _THAT_
much about Linux MM yet (any one got some info?)


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

From: geyer@polyhymnia.IWR.Uni-Heidelberg.de (Helmut Geyer)
Subject: Need tester with 2.88 MB floppy
Date: 15 Jul 1994 05:21:58 GMT

Hello!

I have ported the fdpatch patches (for non-standard floppy geometries as
devices). It seems to work for me. As I don't have a 2.88 MB disk drive,
I cannot test whether it breaks this code. Could
someone that has access to this hardware please contact me.

        Thanks,
                        Helmut


-- 
==============================================================================
Helmut Geyer                                Helmut.Geyer@iwr.uni-heidelberg.de

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

From: luciano@eolo.csr.unibo.it (Luciano Zapparata)
Subject: dlpi support on linux
Date: Fri, 15 Jul 1994 09:50:10 GMT

I'm interested in having information about DLPI (Data Link level 
Provider Interface) support on linux system. Is there anybody who 
can help me?
Thanks

Luciano Zapparata

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

From: cwhk@ic.ac.uk (H.C.W. Kwok)
Subject: mstats.o missing in libc.a
Date: Fri, 15 Jul 94 11:04:15 BST

Hi there,

I just found a curious problem in my Slackware 1.2.0 distribution.

I was writing some code that and I wanted to monitor it the memory
usage by malloc at various stage. So I used the mstats routine defined
in malloc.h as:
                        extern struct mstats mstats __P ((void));
When I complied the program, I had the message that mstats was not 
defined.

So I looked in the libs. using nm, and couldn't find this routine.
But I know this routine does exist in libc.a as I complied gcc
at college:
                >nm libc.a | grep mstats
                mstats.o:
                00000000 T _mstats
Was it a bug in the distribution? And how can I fix the problem
without recompiling/reinstalling gcc on my linux box? (i.e. are
there any files that I can grep and just compile the missing links
and then add to the lib libc.a?)

Thanks  


|==========================================================| 
|   Hansel Kwok < h.kwok@ic.ac.uk >                        |
|   Imperial College of Science, Technology and Medicine   |
|==========================================================|
-- 
|==========================================================| 
|   Hansel Kwok < h.kwok@ic.ac.uk >                        |
|   Imperial College of Science, Technology and Medicine   |
|==========================================================|

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

Crossposted-To: comp.os.linux.misc
From: misch@elara.fsag.de
Subject: Andrew suddenly kills X
Date: Fri, 15 Jul 1994 09:46:32 GMT


Hi world,

I was using the Andrew Toolkit on my system. Everything was running 
fine. Now I changed the computer and now andrew just kills my X. This
is the hardware:

Intel Professional Workstation GX (24 MByte RAM), ATI Ultra with
2 Megs RAM (localbus), XF86_Mach32 (2.1) (options: software cursor
and nolinear)

If I start the andrew wordprocessor and move the mouse pointer out
of it (i.e. to another window) X dumps core. Everything else is
running very fine. Any ideas?


mm.

---
The                                           
Free Software                                      (Phone) ++49-69-6312083
Association of Germany, FSAG                             We have a target!


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

From: pthk@ptb2.pt.tu-clausthal.de (Heinz Kranefeld)
Subject: Re: 1.1.28: SCSI
Date: Fri, 15 Jul 1994 08:00:56 GMT

In article <1994Jul14.115500.20489@solaris.rz.tu-clausthal.de>, pthk@ptb1.pt.tu-clausthal.de (Heinz Kranefeld) writes:
|> 
|> with the kernel 1.1.28 i got funny partition tables from my
|> SCSI disks.

Thanks for your help. 
I have no such problems with 1.1.29.

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

From: jqb@netcom.com (Jim Balter)
Subject: Re: syscall() problem, actual program...
Date: Fri, 15 Jul 1994 07:49:23 GMT

In article <GTHAKER.94Jul12100650@polyphony.sw.stratus.com>,
Gautam Thaker <gthaker@polyphony.sw.stratus.com> wrote:
>In article <2vr72t$miu@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
>
>   In comp.os.linux.development, article <GTHAKER.94Jul8102440@polyphony.sw.stratus.com>,
>   > 
>   > (note: this pgm fails on linux kernel 1.1.13 (and on 0.99pl15f).
>   > 
>   > int foo(int domain, int type, int protocol) {
>   > /* under SUNOS SYS_SOCKET is SYS_socket. */
>   >   return syscall(SYS_SOCKET, domain, type, protocol);
>   > }
>   > 
>   Under Linux, you have to go through the sys_socketcall dispatcher for
>   network calls.
>   SYS_SOCKET is a subcode of this dispatcher. It's defined to 1, which
>   incidentally is the syscall number of exit(), which is the reason why
>   your program terminates. ;-)
>
>   Why don't you use the library code? socket() is there, you know...
>
>   Or get the library sources and look how it's done there if you think you
>   absolutely have to do it yourself. (Hint: you don't.)
>
>
>   Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
>
>Yes, I figured this out after posting. It seems like there is no easy
>way to get to socket() system call without calling socket() itself.
>In Cornell's Horus system (ftp.cs.cornell.edu under pub/horus or
>pub/isis/horus) they define AF_HORUS that gives sockets process group
>semantics. (one gets process groups, causal and atomic message
>ordering properties and all types of neat stuff....)  To achieve this
>they have their own socket() call. Anything not AF_HORUS they redirect
>to syscall(SYS_socket..). Well this does not work under Linux. Easy to
>work around if such calls are limited.  BUt horus uses syscall() for
>all types of socket and networking calls. It is not easy to change
>all these hundreds of calls.
>
>Sigh. Todate I have never had trouble porting any application to Linux.

Just do this:

#ifdef __linux__
#include <sys/socketcall.h>
#include <linux/unistd.h>

static inline _syscall2(long,socketcall,int,call,unsigned long *,args);

int real_socket_systemcall(int family, int type, int protocol)
{
        unsigned long args[3];

        args[0] = family;
        args[1] = type;
        args[2] = protocol;
        return socketcall(SYS_SOCKET, args);
}
#endif /* __linux__ */



-- 
<J Q B>

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

From: schultz_russell@semail.jsc.nasa.gov (Schultz, Russell)
Subject: Linux detecting Turtle Beach MAUI incorrectly
Date: 13 Jul 1994 18:52:32 GMT

Slackware...2.0? (whichever is the latest on sunsite) Using SCSIKERN,
etc.

I installed Linux, everything worked fine.  Installed the MAUI
soundcard, linux diddles for about 3 minutes, and then decides its a
PAS SCSI controller with no hosts attached.

I think the soundcard (MAUI) sits at 0x330 (though thats software
configurable)

It worked the same way with the previous version of Linux i
had(slackware also)

It doesnt seem to affect anything (though i havent tried using the maui
in linux since its mostly unsupported.

Russ.

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

From: jqb@netcom.com (Jim Balter)
Subject: Re: Linux Performance Enhance ?
Date: Fri, 15 Jul 1994 08:41:51 GMT

In article <CsMtGn.BxD@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>In <2vj4pf$k20@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
>
>>In comp.os.linux.development, article <CsK7s3.7Ky@pe1chl.ampr.org>,
>>  pe1chl@rabo.nl writes:
>>> 
>>> Also, it seems like the balance between program pages resident in memory
>>> and pages used for disk buffers is not always optimal: when the memory
>>> is tight it will not swapout infrequently used pages to make room for more
>>> disk buffers.
>>> 
>>Just look at the code in mm/swap.c:
>
>>static int try_to_free_page(int priority)
>>{
>>        int i=6;
>
>>        while (i--) {
>>                if (priority != GFP_NOBUFFER && shrink_buffers(i))
>>                        return 1;
>>                if (shm_swap(i))
>>                        return 1;
>>                if (swap_out(i))
>>                        return 1;
>>        }
>>        return 0;
>>}
>
>>This means, essentially, that the system will always try to shrink the
>>buffer space before attempting to grab a page from a program. Grr.
>
>>Try this replacement instead:
>
>>static int try_to_free_page(int priority)
>>{
>>    int i=5;
>>    static int what = 0;
>>                 
>>    switch(what) {
>>      case 0:
>>        goto what_0;
>>      case 1:
>>        goto what_1;
>>      case 2:
>>        goto what_2;
>>    }                                                         
>
>>  what_0:                                               
>>    if (priority != GFP_NOBUFFER && shrink_buffers(i)) {                        
>>        what = 1;
>>        return 1;
>>    }                                                         
>>  what_1:             
>>    if (shm_swap(i)) {   
>>        what = 2;
>>        return 1;
>>    }                     
>>  what_2:             
>>    if (swap_out(i)) {  
>>        what = 0;
>>        return 1;
>>    }               
>>    if(i-- > 0)       
>>        goto what_0;    
>
>>    return 0;                                                               
>>}                                                                               
>
>>The goto-ish code may be ugly, but jumping into a loop, or duplicating
>>code, is even uglier.
>>In my experience, this change is a noticeable improvement in memory usage.
>
>Aside from the functionality of the above example (which I have not yet
>tested), let me teach you a bit about C programming:
>
>static int try_to_free_page(int priority)
>{
>        int i=6;
>        static int what = 0;
>
>        while (i--) {
>           switch (what)
>           {
>           case 0:
>                if (priority != GFP_NOBUFFER && shrink_buffers(i)) {
>                       what = 1;
>                        return 1;
>               }
>           case 1:
>                if (shm_swap(i)) {
>                        what = 2;
>                        return 1;
>               }
>            case 2:
>                if (swap_out(i)) {
>                        what = 0;
>                        return 1;
>               }
>           }
>        }
>        return 0;
>}
>
>At least this does the same as your code without those ugly goto's.

You have a bit to learn about C programming, yourself.  Your code has a bug:
repeats of the loop will use "what" at the time the routine was entered,
rather than restarting from 0 (e.g., if "what" is 2 upon entry, you will only
call swap_out).

You can fix it by setting what=0 after falling out the switch; this has
trivially different behavior from Matthias' code, in that "what" will always
be 0 if returning 0.  Also, it is slightly slower because it executes the switch
each iteration.  (No, I don't claim that these are significant.)

But we can get exactly the same behavior by using a Duff's Device!

static int try_to_free_page(int priority)
{
        int i = 5;
        static int what = 0;

        switch (what) {
            do {
        case 0:
                if (priority != GFP_NOBUFFER && shrink_buffers(i)) {
                        what = 1;
                        return 1;
                }
        case 1:
                if (shm_swap(i)) {
                        what = 2;
                        return 1;
                }
        case 2:
                if (swap_out(i)) {
                        what = 0;
                        return 1;
                }
            } while (i--);
        }
        return 0;
}

Jumping into a do by putting it inside a switch may seem like an incredible,
horrible hack, but it gives you an excuse for using a Famous Computer Science
Technique (tm).
-- 
<J Q B>

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

From: jqb@netcom.com (Jim Balter)
Subject: Re: Linux Performance Enhance ?
Date: Fri, 15 Jul 1994 08:55:24 GMT

In article <DAVIS.94Jul12144609@pacific.mps.ohio-state.edu>,
John E. Davis <davis@amy.tch.harvard.edu> wrote:
>In article <2vtcrs$78d@smurf.noris.de> urlichs@smurf.noris.de (Matthias
>Urlichs) writes: 
>  > > At least this does the same as your code without those ugly goto's.
>  > > 
>  > Not really...
>  >
>  > It's possible to restart the loop, of course, by setting "what" to zero at
>  > the end, but the generated code is worse. I hate suboptimal code even more
>  > than code with gotos. ;-)
>
>It is true that the two pieces of code are different.  However, even setting
>`what' to zero and re-executing the loop will fail since `what' has been
>declared static.  Here is the original code.  My suggested replacement
>follows.

You are hallucinating.  The fact that "what" is static is irrelevant.

>static int try_to_free_page(int priority)
>{
>   int i = 5;
>   static int what = 0;
>   register int auto_what;

"register"?  Whazat for?  GCC knows how to allocate registers.  You must have
been using some brain-dead AT&T compiler recently.

>   auto_what = what;
>   
>   while (1)
>     {
>        switch (auto_what)
>         {
>           case 0:
>             if (priority != GFP_NOBUFFER && shrink_buffers(i)) {
>               what = 1;
>               return 1;
>             }
>             /* drop */
>           case 1:
>             if (shm_swap(i)) {   
>               what = 2;
>               return 1;
>             }
>             /* drop */
>           case 2:
>             if (swap_out(i)) {
>               what = 0;
>               return 1;
>             }
>          }
>        if (i--) break;
>        auto_what = 0;
>     }
>   return 0;
>}

The only effect of the auto_what is to prevent what from being changed to 0
upon "return 0".

>If you are worried about performance, I suggest that you replace the switch
>with an `if' statement.  However, this might not be necessary with gcc since
>there is an option for it to optimize a switch with jumps.

Of course gcc optimizes case statements; you don't have to tell it to.
Hand coding with if's will just make it slower.
-- 
<J Q B>

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

From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin)
Subject: Re: system("ls") doesn't display anything to screen?
Date: 15 Jul 1994 11:29:42 GMT

Tim Smith (tcsmith@csi.nb.ca) wrote:
> Hello

> Why doesn't system("ls") display anything to the screen. This is the case for
> both c and perl.


Works fine for me. Any more details than that?

-- 
[==================================================================]
[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]

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

From: jqb@netcom.com (Jim Balter)
Subject: Re: Linux Performance Enhance ?
Date: Fri, 15 Jul 1994 09:32:37 GMT

In article <CsuMMo.49F@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>Ok ok...  I admit that my piece of code was not the same as the original.
>So here is a re-try.  It uses no goto at all, generates the same or better
>code as Matthias's version, and it also uses a feature of the C language
>that is not well-known...

Ok, I should have read the whole thread first; I guess I'm not the only one
who knows about Duff's Device!

The fact that several people asked what "feature" is being used suggests
that any use of Duff's Device deserves a big comment describing what's
going on.  The "feature", of course, is the insertion of code after the
switch statement but before the first case statement.  Such code can only
be executed via a goto (implicit in this case).  In fact, the Duff's Device
can be dispensed with by using a goto instead of a while, yielding code much
simpler than Matthias' original without violating his conditions of no code
duplication, no jumping into the middle of a loop (construct), and no
execution overhead:

static int try_to_free_page(int priority)
{
        int i = 5;
        static int what = 0;

        switch (what) {
        default:        /* generates better code than "case 0:" */
        case0:
                if (priority != GFP_NOBUFFER && shrink_buffers(i)) {
                        what = 1;
                        return 1;
                }
                /* fallthrough */
        case 1:
                if (shm_swap(i)) {   
                        what = 2;
                        return 1;
                }
                /* fallthrough */
        case 2:
                if (swap_out(i)) {
                        what = 0;
                        return 1;
                }
                if (i--) goto case0;
        }
        return 0;
}
-- 
<J Q B>

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

From: jqb@netcom.com (Jim Balter)
Subject: Re: Linux Performance Enhance ?
Date: Fri, 15 Jul 1994 09:35:08 GMT

In article <302p3k$drl@senator-bedfellow.mit.edu>,
Andrew Walker <andy@eng.kvaerner.no> wrote:
>Check out the while(i) statement that encloses the switch cases -
>the code jumps into a while loop. To be honest I can't even be bothered
>to check the legality of this in K&R (I think its totally non-intuitive,
>and thus "BAD CODE", but I'd defend it in the kernel if it really
>generates better code).

Duff's Device conforms to the ANSI Standard (it was discussed by the committee).
-- 
<J Q B>

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

From: jqb@netcom.com (Jim Balter)
Subject: Re: Linux seems to perform terribly for large directories
Date: Fri, 15 Jul 1994 09:56:58 GMT

In article <Csq4CH.B3y@news.cern.ch>, Dan Pop <danpop@cernapo.cern.ch> wrote:
>In <CsnzxL.DEn@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes:
>
>>In <1994Jul5.090612.139@dutch.eng.ox.ac.uk> tpfpdt@eng.ox.ac.uk writes:
>>
>>>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.
>
>And there are very good reasons for this. Think about hard links.
>Directory entries are directory entries and inodes are inodes.
>
>Before suggesting "improvements", it's better to understand why things
>are the way they are.

You should read John Bass' filesystem postings over in comp.os.research.  File
info could be stored in directories; additional links can either have
duplicate info (requiring multiple updates) or pointers to the primary link.
Placing inodes in a separate area has a really big performance hit;
traditional filesystems have inodes at the front, ancient stale never-looked
at data in the middle, and nice fresh shiny new files at the end, requiring a
seek across the entire filesystem to get from the metadata to the data.


-- 
<J Q B>

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


** 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
******************************
