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

Linux-Development Digest #216, Volume #2         Fri, 23 Sep 94 18:13:13 EDT

Contents:
  NFS patch (Florian la Roche)
  Re: ncr53c810, Linux, SCSI drive appears multiple times (Mark E. Wallace)
  Errors writing to MSDOS Partition (Bernhard Kappler)
  Re: NCR 53C406A SCSI (Patrick D'Cruze)

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

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

Ooops, just posted the wrong patch...
Seems, I am unable to cancel the previous message. A "D" command
doesn't work right now...

Well, sometimes everything goes wrong...

Please report the release date of 22. sept 94 of this patch in any email...

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]

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

From: [email-masked] (Mark E. Wallace)
Crossposted-To: comp.os.linux.help,comp.periphs.scsi
Subject: Re: ncr53c810, Linux, SCSI drive appears multiple times
Date: 23 Sep 1994 14:16:06 GMT

Adrian Miranda ([email-masked]) wrote:
: I have an NCR53c810 SCSI controller card, and a PCI bus machine.  I'm
: using the Slackware Linux NCR boot disk.  After much pain and misery,
: I got the Linux kernel to see the NCR controller and the SCSI drive.
: The problem is that it thinks I have 7 identical disks, it seems to
: see the same drive on every possible SCSI id.  I can partition the
: disk with fdisk, but when I go into the Slackware setup, it apparently
: sees all the ghost disks, and dies.

: Of course, my NCR53C810 card doesn't have a BIOS on it, and I suspect
: my Motherboard BIOS doesn't support the NCR controller.  The only
: thing the (Award) BIOS has that sounds promising is "On board PCI/SCSI
: BIOS".  I was kind of hoping that meant the BIOS was on board, but I
: suppose it is only for motherboards that have a SCSI controller
: on-board?  Am I out of luck?  Perhaps the Award BIOS can be upgraded
: to a newer version that does support the NCR controller?

: Any help will be greatly appreciated.

: Adrian

This is usually caused by having a SCSI device on your SCSI bus that's
set to the same SCSI ID as your host adapter device. What SCSI ID does
your 53c810 use?

===========================
Mark E. Wallace
[email-masked]

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

From: [email-masked] (Bernhard Kappler)
Subject: Errors writing to MSDOS Partition
Date: 20 Sep 94 07:43:17 GMT

Hello,

I'm running Linux on a 386-33Mhz with 8 MB memory. I've an Adaptec
1542 SCSI Board and a 80MB Disk from SeaGate and a 660MB Disk from HP.
Linux works fine with the ext2 filesystem. Only writing on a msdos
partition almost ever leads to corrupt files. This happens only if
I write a file on my msdos Partion on the harddisk. Floppies do fine.

I found out that files get corrupted doing a "sync" or waiting until
the buffer has been copied to disk.

For example:

        cp file /msdos/file
        diff file /msdos/file

        no differences will be found until the buffer has been flushed 
        to disk.

Doing:  cp file /msdos/file
        sync
        diff file /msdos/file

        will show up differences in over 90% of the tries!!!!

My dos partition uses to second half of the HP disk (the upper cylinders).
I think the disk has about 1400 Cylinders, put I actualy don't know.
The partition was created using fdisk from linux and FAT 16 BIT as 
filesystem.

I hope someone can help me to fix this problem!!!

Bernhard Kappler      [email-masked]

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

From: [email-masked] (Patrick D'Cruze)
Subject: Re: NCR 53C406A SCSI
Date: 24 Sep 1994 04:02:53 +0800

[email-masked] (Kevin Lentin) writes:
>Pete Cascio ([email-masked]) wrote:

>> I've got a Media Vision Pro 3D sound card with SCSI-2.  The SCSI-2 chip is an
>> NCR 53C406A.  It looks like it's probably something new, since it's not
>> mentioned in the SCSI-HOWTO.

>I think Patrick D'Cruze may have solved your problem. Try this:
>    tsx-11.mit.edu:/pub/linux/ALPHA/scsi/acculogic-0.7.README
>                                        /acculogic-0.7.lsm
>                                       /acculogic-0.7.patch.gz

To give credit where credit is due - the author of the ncr53c406a SCSI
driver is Normunds Saumanis ([email-masked]).  I have nothing
to do with the SCSI driver except I occasionally help upload new revisions
of it as Normunds Internet access is a bit shaky.

If anyone is interested in the ncr53c406a SCSI chip or on boards based
around it, you're welcome to join the mailing list for it.  To subscribe,
send email to:
        [email-masked]
with the words:
        subscribe ncr53c406a
in the body of the message.

>-- 
>[==================================================================]
>[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
>[ [email-masked]  |___/~\/~\_____/~\______/~\/~\__| ]
>[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
>[==================================================================]

Regards,
Patrick D'Cruze
[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
******************************