> From: Mike Shaver <shaver@neon.ingenia.com>
> Date: Fri, 23 Jun 1995 04:05:20 -0400 (EDT)
> Subject: Re: Accessing a file by device / inode
>
> Thomas Koenig mumbled something vague about:
> > [The aim of the following is to find a way to eventually icorpoate
> > nfsd into the kernel. ]
>
> Why do you want to integrate nfsd into the kernel? I've always
> thought that the idea would be to migrate as much of it as possible
> away from the kernel, a la selection.
>
> Certainly the ability to open a file from a device/inode pair would be
> useful otherwise, but the rationale seems odd. To me, anyway...
NFS has some strange requirements. Firstly due to brain damage in the
design you need very fast turn around of attributes and similar queries.
Secondly you have this bogoid ope4n by inode need.
> From: Thomas.Koenig@ciw.uni-karlsruhe.de (Thomas Koenig)
> Date: Fri, 23 Jun 1995 11:35:23 +0200 (MET DST)
> Subject: Re: Accessing a file by device / inode
>
> between kernel and user space, which is very expensive;
> an in - kernel nfsd has the possibility to send data right
> out of the buffer cache.
One or two copies. One from the buffer cache to the sk_buff which is
effectively free (it'll do the checksums and fragmnentation too) and one
copy or DMA to the device driver.
> From: "Francisco J. Ballesteros" <nemo@ordago.uc3m.es>
> Date: Fri, 23 Jun 1995 19:41:06 +0200
> Subject: STREAMS for Linux project -- could this be in "official" kernels?
>
> We're starting to make Linux kernels with STREAMS stuff (LiS stuff) in. The
> whole STREAMS project will be surely dust if it's not included in the
> "official" kernel, so I send this mail.
Streams are all well and good if they are fast - very much faster than SCO
streams for example. Otherwise its better to run streams based programs
slowly for compatibility and do things 'properly' for the rest of the
programs.
Think well in advance - copy & checksum, lazy copying for loopback streams
and SMP issues will all matter very very soon, as will streams code that
can support DMA to/from locked user space.
> What do you thing about STREAMS?, Do you think it would be fine to include
> LiS in future kernel releases?
I dislike streams intensely, but thats the existing implementations not the
concept. I don't believe you can build a fast enough streams subsystem
until the day you can assemble streams modules together and optimise the
object code on I_PUSH/I_POP operations.
Alan
Greg writes on the subject of a TCP crash
> note that 1.3.1 and 1.3.2 seemed to offer improved performance of the
> Cyclades driver. We experienced no card lockups with these kernels.
> With 1.3.3 the problem is back, we can elicit a board lockup almost
> at will. As I have said in the past this seems to be related to
> concommitant network activity.
Can you verify if that bug occurs in 1.3.1/2 as well. There are some
1.3.x networking changes in tcp but not many so there is a good chance
of finding it I hope 8)
> concommittant network activity. I find it vaguely discomforting that
> the networking should panic when the Cyclades board is misbehaving.
> We had been doing X-development work from another machine on this
> machine for two solid days before and had never heard a peep out of
> the kernel. Comments, suggestions or experiences would be welcome.
I'd be suprised if the cyclades could crunch the networking by misbehaving
unless its corrupting memory. More likely the networking is crunching the
Cyclades (hey 1.3.x is an ALPHA 8))
Alan
Paul Hargrove writes on NFS etc:
> occured to me. However, along with Linus's intention to make the
> buffer cache addressable by inode/offset, this change could make
> implementation of NFS and HFS much cleaner, with negligible impact on
> the other filesystems.
I'm waiting for Linus on this very much - double/treble NFS speed is
easy once this change is made.
Alan