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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

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: