SRDB ID   Synopsis   Date
21724   RM6 - Array driver returns "Errored I/O, with errno 5" in console   8 Feb 2000

Status Issued

Description
and/or the messages file
Seemingly randomly, the following messages are being printed on the
console and/or the /var/adm/messages file.  They seem to be indicating
a hardware error, but no hardware problems are reported by "health
check" in 'rm6'.

   ---------------------------------------------------------------
     WARNING: The Array driver is returning an Errored I/O, with errno 5,
              on Module 1, Lun 0, sector 140846684
     WARNING: Errored I/O, with errno 5, returned to the Array driver on
              Module 1, LUN 0
     The errored I/O is a write at sector: 140846684
     The errored I/O is being routed to the Resolution daemon
   ---------------------------------------------------------------

SOLUTION SUMMARY:
Although one would immediately think this was a hardware problem, in
reality, these messages may very possibly be caused by an application
attempting to read or write beyond the end of the physical device.
Compare the "errored" block number to the size of the LUN and the slice
being used to see if the errored block is LARGER than the size of the
LUN/slice.

For example, to see if this is truly the case, we run a 'prtvtoc' on
the reported LUN.  For this example, we run

        # prtvtoc -s /dev/rdsk/c2t4d0s2

        *                        First     Sector    Last
        * Partition  Tag  Flags  Sector     Count    Sector  Mount Directory
                0      2    00        0 140845056 140845055   /userdata
                2      5    01        0 140849152 140849151

In this example, the LUN ends at sector 140845055, but the error takes
place at sector 140846684.  This indicates that whatever application is
reading or writing to this LUN has mistakenly attempted an I/O to an
invalid block number, in this case, a block which is beyond the end
of the slice.

The reason it happened in the case presented here was that the customer
had run 'newfs' on slice 2 of the LUN Which was larger), and then
mounted slice 0 (which was smaller).  Everything worked fine until they
attempted to access blocks beyond the end of the slice.  Simply
unmounting slice 0 and mounting slice 2 instead resolved the problem.
SUBMITTER: Chris Kiessling APPLIES TO: Storage/RAID Manager, AFO Vertical Team Docs/Storage ATTACHMENTS:


Copyright (c) 1997-2003 Sun Microsystems, Inc.