david@varian.UUCP (David Brown) (10/06/87)
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!davidhoney@umix.UUCP (Peter Honeyman) (10/09/87)
i wonder if the mt. xinu biod fixes the problem. peter
rob@genrad.UUCP (Robert S. Wood) (10/09/87)
2.0 is much slower than 1.2 was. It has much more code to handle the NFS and YP. Everything is slower. It would be nice if you were not using YP that your directory searches could be faster, but they are not. And NFS is anything but ROBUST. Example. 3 vaxen share nfs files systems one on each remotely mounted to the other two. Users home directories are on hard file-systems, most NFS systems are for reading purposes. If one of the 3 vaxen goes down, a user can not do a pwd on his vax in his home directory until the other vax is back. Some programs, like emacs also will just hang waiting. Not very robust. We have all-but-stopped using NFS until it is fixed.
jdn@mas1.UUCP (Jeff Nisewanger) (10/16/87)
Reply-Path: In article <8588@felix.UUCP> you write: >2.0 is much slower than 1.2 was. It has much more code to handle the >NFS and YP. Everything is slower. It would be nice if you were not >using YP that your directory searches could be faster, but they are not. >And NFS is anything but ROBUST. Example. 3 vaxen share nfs files systems >one on each remotely mounted to the other two. Users home directories are >on hard file-systems, most NFS systems are for reading purposes. If one >of the 3 vaxen goes down, a user can not do a pwd on his vax in his home >directory until the other vax is back. Some programs, like emacs also will >just hang waiting. Not very robust. We have all-but-stopped using NFS >until it is fixed. I haven't noticed 2.0 being generically slower however the memory paging policy seems to have changed so that it pages memory to disk sooner than before and so seems to have to page it back in more often. I don't understand what YP (Yellow Pages) has to do with the speed of reading directories. YP is essentially a network "name server". It also sounds like you should try mounting NFS filesystems soft instead of hard so that file operations don't block forever. On the down side of NFS, I seem to have trouble nfs_umount'ing filesystems. The command returns without any warning or error messages yet I can still access the NFS filesystem after supposedly unmounting it. Jeff Nisewanger Measurex Automation Systems pyramid!voder!mas1!jdn