Subject: Linux-Development Digest #212
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Fri, 23 Sep 94 13:13:10 EDT

Linux-Development Digest #212, Volume #2         Fri, 23 Sep 94 13:13:10 EDT

Contents:
  NFS patch (Florian la Roche)
  Re: [STATUS] Linus Floppy Driver Development (Bill Davidsen)

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

From: [email-masked] (Florian la Roche)
Subject: NFS patch
Date: 23 Sep 1994 11:36:40 +0200

Please report the release date of 23. sept 94 of this patch in any email.
I really should wait 2 days before posting anything to the net.

STILL MISSING THINGS:      23. Sep 1994
=====================

Some people report problems, when executing programs mounted from /usr.
I haven't looked into this, but probably it has something got to do with
the root uid being changed to something else and with suid-root
programs. (I remember X11 to be one problem...)

With my patches, all maybe data corruption problems should be solved.
Such problems are detected and immediately printed as kernel error messages.
If any such messages come up, we have to think again about the correct memory
sizes for nfs packets...

(Anyway, hardware problems seem to be bother the Linux community much more
than any bugs left in the kernel...   :-)

CHANGES FROM PREVIOUS PATCHES:
==============================

I added a missing detection about wrong memory sizes in sock.c. Now
you should see a kernel-printk-line, if NFS still uses too small
buffers... Data corruption could have happened here in the kernel.
More detailed report:
A udp datagram was too big to fit in the offered memory, so just the
first part was copied. Since it doesn't return a negative value, the code
in the nfs part goes on working. It will just use the memory directly after
the kmalloced memory for the rest of the data. Since that is normally user
data, it doesn't have to be checked further and may be copied up to user
level...  This is only the case for reading, so no memory in the kernel
could be corrupted by this, but just user data.

Now, I have also added some more checks about the used memory sizes.
Previously, just assumptions were made about the size of the next packet.
(If the server disagrees, you might get screwed up...)

The biggest change in this version is a suggested buf-fix from Peter Eriksson.
Linux should now be less often confused and talk much better to the NFS-server.
Please look into the linux/fs/nfs/ directory after applaying the patch.
I have included the original message from Peter.

NFS read-ahead and improved code:
=================================

Here is a patch to the kernel version 1.1.51. It can be applied also
to most other kernel versions since that part didn't change in the
last time...

I recoded the existing patch that implements read-ahead for NFS. That old patch
sometimes crashes the machine, since it copied data to the user level with
interrupts turned off. (And if the page isn't present, you will get...)
I put in also a timeout for that cache. Since the cache only contains up
to 5 entries, this will normally not be a problem, but I wanted to make this
100% sure...

There should be also some further speed improvements from better coding
technics and less copying of the data in the kernel. (Though parts of the
code look now more ugly.)

Note that read requests that are done via mmap are not cached. Most times,
that will be only for shared libraries. Also linux will then do nearly all
requests with a size of 4096 (PAGE_SIZE) and will not fetch such a
page a second time without need for it. So enhancing read-ahead for mmap
requests also is not a big win...
(But it is a big win to set rsize to at least 4096...)

Data corruption with NFS?
=========================

You can speed up NFS by specifying rsize=8192 and wsize=4096. Without any
mount options, this patch won't make Linux faster.
(mount nfs.server.edu:/export/linux/usr  /usr -o rsize=8192,wsize=4096)

Please try the following, to see, that data from your nfs server is copied
100% correct:
        (cd /nfs/mounted/directory; tar cf - .) | tar xf -
and then doing several times (on 2 consoles?)
        (cd /nfs/mounted/directory; tar cf - .) | tar df -
People used to report data corruption here... Please also have a look at the
kernel messages, when you run this test...
(I use sysklogd version 1.2 and just put "*.*  /dev/tty8" to monitor all
such warnings on my VC 8)

What about implementing real caching of NFS?
============================================

The buffer cache uses the device number and the block number of that device
to do the buffer caching. For nfs, we would also need to make buffer entries
with device(mount point?), inode number, offset. These entries also need
some (user adjustable) timeout value (3 seconds?).
(Hi Olaf, this is described just the other way round in your great nag 1.0,
if I am not totally wrong here. But I will send you some other small problems
soon as well...)
I might start implementing this...

Speed improvements by doing read-ahead:
=======================================

I use always rsize=8192 and wsize=4096.

I mounted the kernel source and did a "make config; touch .depend; make".
I got 12454 read requests, 2662 could be taken out of the cache.
That is 21% less requests over the net...

Mounting /usr/X386 via NFS, doing one "startx" with fvwm and one xterm window,
without that additional stuff that fvwm normally prints on startup, I get:
245 read requests, where 171 can be taken out of the cache. (Sounds horrible
good so far...) (Note that mmapping the shared libries for X11 doesn't count
in these statistics.)

Well, I got several pretty enthusiastic emails. (One saying from minimum 2 up
to more than 3 times faster. Others believe in a 3 up to 4 times faster...)
I am too lazy to copy parts of those email right now, but people seem to like
this patch...

INSTALLATION:
=============

Go into the kernel source tree (.../linux/) and do a "patch -s -p0 < this_file".
Then recompile the kernel...

Florian  La Roche               [email-masked]

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

From: [email-masked] (Bill Davidsen)
Subject: Re: [STATUS] Linus Floppy Driver Development
Date: 23 Sep 1994 09:20:18 -0400

In article <[email-masked]>,
Larry Doolittle <[email-masked]> wrote:

:: This is not bloat, it's an important issue for some people.
:
:OK, it's an issue.  But it's bloat if it goes in the Kernel.
:This situation cries out for a Kernel hook, and the ability
:to have a floppy_mount_daemon that gets activated when the
:user puts in a floppy (periodic disk-change check?).

:Personally, I would never run such a daemon.  I know people
:who would, though.  Any volunteers to write such a beast?

Or you could put it in the floppy driver and make it loadable.
I'm about 80% sure the floppy driver is a loadable one, I just
don't have a system handy to check.
-- 
Speaking *from* but never *for* Prodigy
        "Pain builds moral fiber"  -my dad
        "Pain hurts"  -me

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

** 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: [email-masked]

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

    Internet: [email-masked]

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