Tech Insider					   Technology and Trends

			   USENET Archives

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!
From: da...@varian.UUCP (David Brown)
Newsgroups: comp.unix.ultrix
Subject: letter from DEC
Message-ID: <8407@felix.UUCP>
Date: Tue, 6-Oct-87 12:19:59 EDT
Article-I.D.: felix.8407
Posted: Tue Oct  6 12:19:59 1987
Date-Received: Sat, 10-Oct-87 10:50:25 EDT
Sender: ze...@felix.UUCP
Organization: Varian, Walnut Creek CA
Lines: 93
Keywords: NFS and corrupted files
Approved: ze...@felix.UUCP (Art Zemon)

Last week I received the following from DEC.  I thought I'd post to
make sure that everyone saw it (and also to try out our new Datacopy
scanner and OCR software -- I scanned it in).

Perhaps this is related to the file corruption problem that Art
experienced a while back?  Was that ever resolved?  We've refrained from
installing V2.0 on our 750 (currently running V1.2) until we learned
more about filesystem robostness of V2.0.  We currently don't run NFS,
but that was one of the primary reasons we wanted to convert to V2.0.

(The other was a hope for performance throughput - does anyone know if
2.0 will run faster (or slower) on a 750?  Is there any hope of getting
the TU80 to stream, or at least move a bit faster?)

                                         25 September 87


We have identified a problem situation with ULTRIX-32(TM)
Version 2.00. Below is a detailed solution which, when
installed, will remedy this problem situation. This
solution is also available on the Digital Software
Inforation Network, if you are a Basic or DECsupport


It is likely that corruption of files written remotely over
NFS will result in the client system when block I/O daemons
(/etc/biod) are running. This situation can occur when
using ULTRIX clients with either ULTRIX or non-ULTRIX NFS
servers. It does not appear on non-ULTRIX clients with
ULTRIX servers.

The symptom of the corruption is the loss of output from
write(2) operations. When the file is new, this loss
results in bytes of data with zero values. Because the
problem is intermittent and rarely seen, it is usually
corrected by re-running the program. All reported cases of
the problem have involved the program loader ld(l).


The likelihood of corruption occurrence is greater when the
server filesystem block size is less than 8K or when the
transfer sizes have been reduced from the defaults with
mount options. The relative speeds of client and server
processors and/or processor loads can also affect the
likelihood of encountering the problem. Those that
originally reported this problem were writing to a 4K server

The following work-around MUST be installed on all client
systems. Since the problem can only occur when block I/O -
daemons are running. running without them will assure that
this problem does not occur. The block I/O daemons.
/etc/biod. are invoked from the startup file /etc/rc.local
when the system starts up.

To terminate the block I/O daemons on a system that has
already run nfssetup. edit the rc.local file and comment out
the lines that contain the /etc/biod invocation, as follows,

#if [ -f /etc/biod ]; then
# /etc/biod 4 & echo -n ' biod' >/dev/console

Then reboot the system.

To prevent the block I/O daemons from running on a system
that you are setting up, use the NFS setup script, nfssetup,
to modify the startup file. When the NFS setup script
prompts you to enter the number of block I/O daemons to run,
enter O (zero).

We believe this solution will help you to successfully avoid
a problem with ULTRIX-32(TM) Version 2.00.



David Brown	 (415) 945-2199
Varian Instruments 2700 Mitchell Dr.  Walnut Creek, Ca. 94598

			   USENET Archives

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 

Electronic mail:			      WorldWideWeb: