Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!pyramid!oliveb!felix!zemon
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
DEAR ULTRIX-32(TM) CUSTOMER:
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
customer.
PLESE READ AND INSTALL
PROBLEM STATEMENT:
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).
SOLUTION/PATCH
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
filesystem.
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
#fi
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.
Regards.
SOFTWARE PRODUCT SERVICES
--
David Brown (415) 945-2199
Varian Instruments 2700 Mitchell Dr. Walnut Creek, Ca. 94598
{ptsfa,lll-crg,zehntel,dual,amd,fortune,ista,rtech,csi,normac}!varian!davi
|