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

Linux-Development Digest #214, Volume #2         Fri, 23 Sep 94 15:13:14 EDT

Contents:
  NFS patch (Florian la Roche)

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

From: [email-masked] (Florian la Roche)
Subject: NFS patch
Date: 22 Sep 1994 21:38:54 +0200

Sorry for these frequently postings...

Please write in any email messages to me, exactly what patch you are using.
E.g.: Say the patch from 22. sept...

STILL MISSING THINGS:      22. 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...)

Everything else seems to be ok.
Nobody has emailed me about data corruption any more, so I think these
problems have gone.

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

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

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.

The main problem now is the data corruption with bigger packets that only
some people report. Please read further down in this text for more...
(This shouldn't be true any more...)

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)

Note: The following shouldn't be true any more. Please give it really hard
tests...
However, some machines don't work with this. Random data corruption occurs.
You can test this with:
        (cd /nfs/mounted/directory; tar cf - .) | tar xf -
and then doing several times (on 2 consoles?)
        (cd /nfs/mounted/directory; tar cf - .) | tar df -
Data corruption seems to be dependent on that rsize value. With 2048 it nearly
never happens, with 4096 after sveral hours, with 8192 pretty fast.
I myself have tested my machine very excessive and could never make such a
data corruption happen.
Could those people, that have such data corruption, please email me their
exact configurations of the server side? Are udp checksums enabled on the
server side?  Can someone use a network analysor on this?
Can I login somewhere on a test machine, that doesn't have valuable data
on it?

If the Linux side is responsible for that data corruption, than the bug
is most probably in fs/nfs/sock.c. I have read all other .c-files and they
seem to be ok...

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]

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

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