SUMMARY: VMUBC write error

From: Didier Wagenknecht, Security Officer, ADM-SIC, EPFL <wagen_at_slalpha1.epfl.ch>
Date: Thu, 18 May 1995 09:11:52 +0200

Dear Netlanders,

>Help! It's now my turn to have the
>UBC write error(4) on device (0, 0) at block 19808 size 8192
>on the console ! I checked the archives to see if someone knows
>what this means, but no info. Is this informational, warning,
>error, fatal error, or simply crash in progress ? Where does it come
>from ? Advfs ? Osf UBC management ? Is it still normal with osf 3.2A ?

Here is the summary, and as usual Dr Blinn win the price for the best answer!
The message is simply informational, no needs to worry. The complete explanation
is below:

===============================================================================
From: "Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com>

Didier, it's largely informational. I looked in the support pool for the
V3.2 release, and it looks like a patch is in progress but hasn't yet been
released.

The error message is issued in the module vfs_ubc.c in the routine called
ubc_async_iodone_lwc() which handles "Async I/O done LWC" (whatever that is)
and there are a NUMBER of conditions that can cause the message display.

In general, the message is merely informational; the write gets retried and
generally succeeds. The patch disables the display of the message, but has
a flag to turn it back on, and maintains a count of the number of times the
message would have been displayed. The comment for the patch says:

 * Do not print UBC write error messages. NFS errors tend to cause too
 * many of them to be printed to the console. Printing can be enabled
 * if needed by assigning a non-zero value to ubc_error_print.

So, I'd interpret this as "don't panic". I talked to the person who wrote
the patch, and apparently the same problem gets logged in the NFS daemon
logs, where it's typically caused by a stale file handle -- for instance, a
system that you want to update a file page to is down.

The patch was put into the maintenance pool on 04/26 so I'm sure it will be
in the hands of the CSCs sometime in the not too distant future, once it has
been through the formal review process. The patch author believes it has
been released, but I don't see a description in the local "readme" file for
it, so it is probably still in process.

Tom

============
From: alan_at_nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for Wayward Inodes.)

The error(#) seems to be the errno value that was set as the
result of a write failure from the Unified Buffer Cache. The
block and I/O size are probably correct. The device number
is wrong, but experience suggests it was an NFS file system.
Errno #4 on my V3.2 system is EINTR, interrupted system

=============
Thanks also to "Becki S Kain" <kain_at_cc5038.pms.ford.com>, who replied,
but couldn't be of more assistance.

Cheers,

Didier
_____________________________________________________________
  Didier Wagenknecht, Service Informatique Central (SIC/SL)
  Ecole Polytechnique Federale de Lausanne
  CH-1015 Lausanne (Switzerland)
  E-mail : wagen_at_sic.adm.epfl.ch
  Phone : (+41.21) 693.22.18, Fax : (+41.21) 693.22.20
Received on Thu May 18 1995 - 03:12:34 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:45 NZDT