PowerPath AIX: Anwendungen stürzen ab und LVM_IO_FAIL mit FEHLERCODE GEMÄSS DEFINITION IN sys/errno.h 22 (EINVAL)

Verlust eines Pfads

Umwelt:
Dell Software: PowerPath for AIX (jede Version)

Wenn in einer von PowerPath verwalteten Konfiguration mit mehreren Pfaden ein Pfad ausfällt und obwohl andere Pfade verfügbar sind, fällt die Anwendung aus. Und LVM_IO_FAIL mit der Einstellung "ERROR CODE AS DEFINED IN sys/errno.h" auf 22 werden aufgezeichnet.

Die mit "summ" dekodierten Fehler werden wie folgt angezeigt:

107769 Apr 12 08:57:21 LVDD       P LVM_IO_FAIL         LV 8000002C00000003 PV 800000250000001A Block 20016620 EINVAL

(reale LVM_IO_FAIL, die sich aus Fehlern auf allen Pfaden ergeben, werden normalerweise mit Fehlernr. 5 (EIO) in Verbindung gebracht ... was hier nicht der Fall ist)

LABEL:        LVM_IO_FAIL
IDENTIFIER:    E86653C3

Date/Time:       Sun Apr 12 10:09:28 2020
Sequence Number: 108111
Machine Id:      0XXXXXXXXXXX
Node Id:         snode1
Class:           H
Type:            PERM
WPAR:            Global
Resource Name:   LVDD
Resource Class:  NONE
Resource Type:   NONE
Location:

Description
I/O ERROR DETECTED BY LVM

Probable Causes
POWER, DRIVE, ADAPTER, OR CABLE FAILURE

    Recommended Actions
    RUN DIAGNOSTICS AGAINST THE FAILING DEVICE

Detail Data
PHYSICAL VOLUME DEVICE MAJOR/MINOR
8000 0025 0000 0029
ERROR CODE AS DEFINED IN sys/errno.h
          22
BLOCK NUMBER
             392149792
LOGICAL VOLUME DEVICE MAJOR/MINOR
8000 002D 0000 0001
PHYSICAL BUFFER TRANSACTION TIME
                     0
RESIDUAL COUNT
               1048576
NUMBER OF BLOCKS
               1048576
I/O TYPE
USER DATA
SENSE DATA
0000 0000 0002 EBF7 00F6 D020 0000 4C00 0000 013D 10F0 F4AD 00F6 D020 3831 80BE
0000 0000 0000 0000

Dieser Fehler wird erzeugt, wenn der I/O-Puffer bei Upstream (FS/LVM) nicht an den Festplattentreiber übertragen wird. (hier PowerPath - aber das Problem konnte auch in einer MPIO-Umgebung auftreten) hdiskpower).

In IBM ausgedrückt: Dieser LVM-I/O-Fehler (EINVAL) wird gemeldet, wenn PCM (powerpath) die I/O-Anforderung vom LVM nicht verarbeiten kann, da es zu einer Nichtübereinstimmung der VG LTG-Größe (LVM-I/O-Puffer) mit der Größe der Festplatte max_transfer oder max_xfer_size des Adapters kommen könnte (NPIV hier).

Wenn die Logical Track Group (LTG) größer ist als die Größe des Festplattentreibers max_transfer, kann die I/O nicht verarbeitet werden und es wird ein LVM_IO_FAIL erzeugt, wobei erno auf 22 (EINVAL) festgelegt ist.

In unserem Fall hatten wir (private Kundendaten wurden geändert):

VOLUME GROUP:       vgdata1                  VG IDENTIFIER:  00f6d02000004c0000000145a924a9d9
VG STATE:           active                   PP SIZE:        256 megabyte(s)
VG PERMISSION:      read/write               TOTAL PPs:      36387 (9315072 megabytes)
MAX LVs:            512                      FREE PPs:       746 (190976 megabytes)
LVs:                3                        USED PPs:       35641 (9124096 megabytes)
OPEN LVs:           3                        QUORUM:         7 (Enabled)
TOTAL PVs:          13                       VG DESCRIPTORS: 13
STALE PVs:          0                        STALE PPs:      0
ACTIVE PVs:         13                       AUTO ON:        yes
MAX PPs per VG:     127000
MAX PPs per PV:     5080                     MAX PVs:        25
LTG size (Dynamic): 1024 kilobyte(s)         AUTO SYNC:      no
HOT SPARE:          no                       BB POLICY:      relocatable
PV RESTRICTION:     none                     INFINITE RETRY: no
DISK BLOCK SIZE:    512                      CRITICAL VG:    no
FS SYNC OPTION:     no                       CRITICAL PVs:   no

und

# lsattr -El hdisk25

PR_key_value   none               Persistant Reserve Key Value     True
clr_q          yes                Device CLEARS its Queue on error True
location                          Location Label                   True+
lun_id         0x0                Logical Unit Number ID           False
lun_reset_spt  yes                FC Forced Open LUN               True
max_coalesce   0x100000           Maximum Coalesce Size            True
max_retries    5                  Maximum Number of Retries        True
max_transfer   0x40000            Maximum TRANSFER Size            True
node_name      0x5000144041111111 FC Node Name                     False
pvid           none               Physical volume identifier       False
q_err          no                 Use QERR bit                     True
q_type         simple             Queue TYPE                       True
queue_depth    32                 Queue DEPTH                      True+
reassign_to    120                REASSIGN time out value          True
reserve_policy no_reserve         Reserve Policy                   True
reset_delay    0                  Reset Delay                      True
rw_timeout     30                 READ/WRITE time out value        True
scsi_id        0x72ff40           SCSI ID                          False
start_timeout  60                 START UNIT time out value        True
ww_name        0xc001448111111111 FC World Wide Name               False

Hier haben wir max_transfer = 0x40000 (256 kB) < LTG (1024 kB) (0x100000) .., die das Problem verursacht.

In der Konfiguration waren einige Festplatten mit "max_transfer" auf 0x100000 und andere auf 0x40000 eingestellt (wahrscheinlich mit unterschiedlichen ODM-Versionen erzeugt). Wenn alle Pfade verfügbar waren, gab es immer eine der Festplatten jeder hdiskpower, wobei max_transfer auf 0x100000 eingestellt war, und die I/O konnte abgeschlossen werden. Aber als diese Festplatte nicht mehr verwendbar war, waren nur die Festplatten mit max_transfer auf 0x40000 gesetzt... das Problem verursacht hat.

Um das Problem zu beheben, muss das Attribut "max_transfer" der Festplatte auf einen Wert festgelegt werden, der größer oder gleich der LTG-Größe ist. In unserem Fall mit LTG = 1024 kB wurde Folgendes ausgeführt, um das Problem zu beheben:

# for i in `lsdev -Cc disk |grep -i hdiskp |awk '{print $1}'`
do
chdev -l $i -a max_transfer=0x100000 -P
done
# for i in `lsdev -Cc disk |grep -i EMC |awk '{print $1}'`
do
chdev -l $i -a max_transfer=0x100000 -P
done
# reboot

Dieser Wissensdatenbank-Artikel gilt nicht für LVM_IO_FAIL, bei denen errno auf 5 (EIO) festgelegt ist.