Fehlersuche bei Problemen mit extendlv und Dateisystem-Vergrößerung

Beim Vergrößern von Logical Volumes oder Dateisystemen kommt es häufig zum Fehler “0516-404 allocp: This system cannot fulfill the allocation request“. Viele AIX Administratoren sind dann erst einmal etwas ratlos, was die Ursache für das Problem ist: liegt es an max LPS oder upper bound, an der gewählten Strictness oder hat das Problem ganz andere Ursachen. Die Fehlermeldung ist leider nur generisch und sagt nicht was das eigentliche Problem ist. Eine gute Möglichkeit dem Problem auf den Grund zu gehen, ist der alog lvmt, in diesem werden alle LVM Aktionen, insbesondere der Low-Level Kommandos, inklusive Fehlermeldungen mitprotokolliert. Im Folgenden soll anhand von einer Reihe von Beispielen gezeigt werden, wie nützlich dieser Log ist, um in vielen Fällen relativ schnell die Ursache des geschilderten Problems zu finden.

1. Erfolgreiche Erweiterung

Als erstes schauen wir uns den alog lvmt einmal für eine erfolgreiche Dateisystem-Erweiterung an. Wir erweitern ein kleines Dateisystem um lediglich 8 MB, das entspricht in unserem Fall genau der PP (Physical Partition) Größe:

# chfs -a size=+8M /fs01
Filesystem size changed to 2097152
#

Den angesprochenen lvmt Log kann man mit Hilfe des Kommandos alog und der Option “-o” ausgeben:

# alog –t lvmt –o
…
[S 12255362 16908296 03/22/21-19:10:28:736 extendlv.sh 789] extendlv fslv01 1
…
[S 13500646 12255362 03/22/21-19:10:28:900 allocp.c 1425] allocp -i 00ca0a6000004b00000001785af0a43e.1 -t e -c 1 -s 1 -u 1024 -e m -a m
[3 13500646 0:047 allocp.c 1226] get_pv_mirror_pool: LV not using mirror pools.
[E 13500646 0:047 allocp.c 1558] allocp: exited with rc=0
…
[E 12255362 0:763 extendlv.sh 33] extendlv: exited with rc=0
#

Man sieht, das das Kommando extendlv gestartet wurde, wobei hier nur um eine LP (Logical Partition) erweitert wird. Das Allozieren der benötigten PPs übernimmt das Intermediate Kommando /usr/sbin/allocp. Dieses wird mit einer Reihe von Argumenten aufgerufen:

-i    LVID of the logical volume
-t    logical volume type
-c    number of LV copies
-s    number of logical partitions
-u    maximum number of physical volumes (upper bound)
-e    inter physical volume allocation policy
-a    intra physical volume allocation policy

Die Meldung „LV not using mirror pools“ deutet klar an, das vom Logical Volume keine Mirror Pools verwendet werden. Verwendet ein Logical Volume Mirror Pools, dann fehlt diese Zeile in der Ausgabe. Das Fehlen der Meldung ist also ein Hinweis auf die Verwendung von Mirror Pools!

Das Kommando allocp war erfolgreich: „exited with rc=0“. Letztlich war damit dann auch das extendlv erfolgreich.

2. Max LPs ist zu klein

In unserem ersten Fall ist ein Blick in den lvmt Log nicht notwendig, da hier die Fehlermeldung direkt auf das Problem hinweist. Da genau dieser Fall aber recht häufig vorkommt, haben wir ihn der Vollständigkeit halber mit aufgenommen:

# chfs -a size=+2G /fs01
0516-787 extendlv: Maximum allocation for logical volume fslv01
        is 512.
#

Die Fehlermeldung deutet eindeut daraufhin das der Parameter Max LPs zu klein ist:

# lslv fslv01
…
MAX LPs:            512                    PP SIZE:        8 megabyte(s)
…
#

Das Problem lässt sich mit Hilfe von chlv sehr leicht beseitigen:

# chlv -x 1024 fslv01
# chfs -a size=+2G /fs01
Filesystem size changed to 10305536
Inlinelog size changed to 20 MB.
#

3. Nicht genügend freie PPs in der VG

Beim Versuch ein bestehendes Dateisystem um 10 GB zu erweitern bekommen wir folgende Fehlermeldung:

# chfs -a size=+10G /fs01
0516-404 allocp: This system cannot fulfill the allocation request.
        There are not enough free partitions or not enough physical volumes
        to keep strictness and satisfy allocation requests.  The command
        should be retried with different allocation characteristics.
#

Hier der zugehörige Auzug aus dem lvmt Log:

# alog –t lvmt –o
…
[S 21889060 4128932 03/22/21-20:04:19:854 extendlv.sh 789] extendlv fslv01 1280
…
[S 19398754 21889060 03/22/21-20:04:20:040 allocp.c 1425] allocp -i 00ca0a6000004b00000001785af0a43e.1 -t e -c 1 -s 1280 -u 1024 -e m -a m
[3 19398754 0:055 allocp.c 1226] get_pv_mirror_pool: LV not using mirror pools.
[1 19398754 0:055 allocp.c 999] allocp: FAIL: total_avail_pps(1012)<(size(1280)*requests_unfilled(1)
[E 19398754 0:055 allocp.c 1558] allocp: exited with rc=-1
…
[E 21889060 0:346 extendlv.sh 33] extendlv: exited with rc=1
#

Das Logical Volume fslv01 wird um 1280 LPs erweitert und es sind keine Mirror Pools im Spiel. Die Fehlermeldung von allocpFAIL: total_avail_pps(1012)<(size(1280)*requests_unfilled(1)“ besagt, das aktuell nur 1012 PPs frei sind, und damit nicht 1280 PPs alloziert werden können.

Ein Blick auf die VG zeigt, das in der Tat nur noch 1012 PPs frei sind:

# lsvg vg00
…
MAX LVs:            256                      FREE PPs:       1012 (8096 megabytes)
…
#

Ohne zusätzliche Plattenkapazität ist die gewünschte Erweiterung nicht möglich. Es können aktuell maximal 8 GB dem Dateisystem hinzugefügt werden.

4. Upper Bound ist zu niedrig

Auch in dem folgenden Beispiel schlägt die Erweiterung eines Dateisystems fehl:

# chfs -a size=+10G /fs01
0516-404 allocp: This system cannot fulfill the allocation request.
        There are not enough free partitions or not enough physical volumes
        to keep strictness and satisfy allocation requests.  The command
        should be retried with different allocation characteristics.
#

Wir schauen wieder in den lvmt Log:

# alog –t lvmt –o
…
[S 12386466 15007772 03/22/21-20:16:36:273 extendlv.sh 789] extendlv fslv01 1280
…
[S 7274510 12386466 03/22/21-20:16:36:507 allocp.c 1425] allocp -i 00ca0a6000004b00000001785af0a43e.1 -t e -c 1 -s 1280 -u 1 -e m -a m
[3 7274510 0:103 allocp.c 1226] get_pv_mirror_pool: LV not using mirror pools.
[1 7274510 0:103 allocp.c 999] allocp: FAIL: total_avail_pps(1012)<(size(1280)*requests_unfilled(1)
[E 7274510 0:103 allocp.c 1558] allocp: exited with rc=-1
…
[E 12386466 0:431 extendlv.sh 33] extendlv: exited with rc=1
#

Die Meldungen im Log sehen genauso aus, wie im vorigen Beispiel. Ein Blick auf die Anzahl der freien PPs in der VG, zeigt allerdings, das es genügend freie PPs gibt:

# lsvg vg00
…
MAX LVs:            256                      FREE PPs:       3454 (27632 megabytes)
…
#

In der VG gibt es 3454 freie PPs. In der Meldung „FAIL: total_avail_pps(1012)<(size(1280)*requests_unfilled(1)” aus dem lvmt Log wird aber von nur 1012 verfügbaren PPs ausgegangen! Bei genauerem Blick sieht man, das das Intermediate Kommando allocp mit der Option „-u 1“ aufgerufen wurde, d.h. das für das Logical Volume maximal 1 Physical Volume verwendet werden darf. Das LV darf also aktuell nur zusätzlichen Platz auf dem schon vom LV verwendeten Physical Volume (hier hdisk2) verwenden.

Wir erhöhen Uppber Bound auf 2:

# chlv -u 2 fslv01
#

Und versuchen dann die Erweiterung erneut:

# chfs -a size=+10G /fs01
Filesystem size changed to 25214976
Inlinelog size changed to 49 MB.
#

Was dieses mal erfolgreich ist.

5. Problem wegen Strictness=yes

Die Erweiterung eines gespiegelten Dateisystems schlägt fehl:

# chfs -a size=+10G /fs01
0516-404 allocp: This system cannot fulfill the allocation request.
        There are not enough free partitions or not enough physical volumes
        to keep strictness and satisfy allocation requests.  The command
        should be retried with different allocation characteristics.
#

Im lvmt Log sind dazu die folgenden Meldungen zu finden:

# alog –t lvmt –o
…
[S 13762618 19857542 03/23/21-10:53:06:616 extendlv.sh 789] extendlv fslv01 1280
…
[S 14352436 13762618 03/23/21-10:53:06:837 allocp.c 1425] allocp -i 00ca0a6000004b00000001785af0a43e.1 -t e -c 2 -s 1280 -u 3 -e m -a m
[3 14352436 0:098 allocp.c 1226] get_pv_mirror_pool: LV not using mirror pools.
[2 14352436 0:115 map_alloc.c 2057] figure_min_alloc: WARN: Could not fulfill allocation, num_lps_to_fill=109
[E 14352436 0:115 allocp.c 1558] allocp: exited with rc=-303
…
[E 13762618 0:431 extendlv.sh 33] extendlv: exited with rc=1
#

Auf den Physical Volumes in der VG gibt es noch freie Kapazitäten:

# lsvg -p vg00
vg00:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk2            active            1271        1143        255..126..254..254..254
hdisk3            active            1271        1171        255..154..254..254..254
hdisk4            active            1271        1143        255..126..254..254..254
hdisk5            active            1271        1171        255..154..254..254..254
#

In der Summe sollte das eigentlich ausreichend sein, aber laut Fehlermeldung „WARN: Could not fulfill allocation, num_lps_to_fill=109“ können 109 PPs nicht alloziert werden. Das Intermediate Kommando allocp wurde mit „-u 3“ gestartet, es dürfen also insgesamt vom LV bis zu 3 Physical Volumes verwendet werden. Aktuell verwendet das LV die beiden Physical Volumes hdisk2 und hdisk4:

# lslp fslv01
fslv01:/test
LPs           #LPs   COPY1                 COPY2                 COPY3              
0001-0128     128    hdisk2 (None)         hdisk4 (None)         -                  
#

(Das Kommando lslp ist ein von uns geschriebenes Shell-Skript, um die LPs von Logical Volumes übersichtlich darzustellen. Es basiert letztlich auf „lslv -m„.)

D.h. das neben hdisk2 und hdisk4 für die Allozierung noch entweder hdisk3 oder hdisk5 verwendet werden könnten. In der Summe käme man dann auf 2 * 1143 + 1171 = 3457 freie PPs. Benötigt werden für die Erweiterung nur 2 * 1280 = 2560 PPs. Allerdings kommen jetzt noch die Strictness und die Allocation Policies ins Spiel. Die Strictness ist hier yes und die Inter Physical Volume Allocation Policy ist min („-e m“). D.h. von den 3 Physical Volumes hdisk2, hdisk3 und hdisk4 wird zunächst Platz von dem ersten Physical Volume (hdisk2) für die Spiegel-Kopie 1 alloziert, es stehen 1143 PPs auf hdisk2 zur Verfügung (damit fehlen dann noch 137 PPs für die erste Spiegel-Kopie). Dann wird von dem zweiten Physical Volume (hdisk3) Platz für die Spiegel-Kopie 2 alloziert, auch dort stehen noch 1143 PPs zur Verfügung. Dann geht es mit der hdisk4 und der Spiegel-Kopie 1 weiter. Die noch fehlenden 137 PPs stehen auf hdisk4 zur Verfügung und werden der Spiegel-Kopie 1 zugewiesen. Dann geht es weiter mit der Spiegel-Kopie 2. Auf hdisk2 gibt es keinen freien Platz mehr, daher wird als nächstes hdisk3 herangezogen, dort sind noch 28 PPs verfügbar, die dann der Spiegel-Kopie 2 zugewiesen werden. Damit fehlen in Spiegel-Kopie 2 noch 109 PPs. Diese können aber nicht mehr alloziert werden, da das einzige Physical Volume mit noch freier Kapazität die hdisk4 ist, welche allerdings schon von Spiegel-Kopie 1 verwendet wird. Die Verwendung von hdisk4 für die fehlenden 109 PPs in Spiegel-Kopie 2 würde die Strictness=yes verletzen, da dann beide Spiegel-Kopien für die letzten 109 LPs auf hdisk4 liegen würden.

Die Meldung „WARN: Could not fulfill allocation, num_lps_to_fill=109” ist also ein Hinweis darauf das die Strictness nicht eingehalten werden kann.

6. Keine ausreichende freie Kapazität in den verwendeten Mirror Pools

Auf einem System werden die Mirror Pools DC01 und DC02 verwendet. Eine Erweiterung eines Dateisystems schlägt fehl:

bash-4.3# chfs -a size=+512M /fs01
0516-404 allocp: This system cannot fulfill the allocation request.
       There are not enough free partitions or not enough physical volumes
        to keep strictness and satisfy allocation requests.  The command
        should be retried with different allocation characteristics.
bash-4.3#

Hier die zugehörigen Meldungen aus dem lvmt Log:

# alog –t lvmt –o
…
[S 7929950 9502800 03/23/21-11:56:56:506 extendlv.sh 789] extendlv fslv01 64
…
[S 10354926 7929950 03/23/21-11:56:56:785 allocp.c 1425] allocp -i 00ca0a6000004b00000001785af0a43e.1 -t e -c 2 -s 64 -K 2 -u 4 -e m -a m
[1 10354926 0:189 map_alloc.c 1963] figure_min_alloc: FAIL: num_lps_to_file=9
[S 10354942 7929950 03/23/21-11:56:57:004 putlvodm.c 1370] putlvodm -K 00ca0a6000004b00000001785af0a43e -X 0
…
[E 7929950 0:565 extendlv.sh 33] extendlv: exited with rc=1
#

Es fehlt der Hinweis das keine Mirror Pools verwendet werden! Es sind also Mirror Pools im Einsatz!

Daher listen wir die Zuordnung der Physical Volumes zu den Mirror Pools einmal auf, um uns einen Überblick zu verschaffen:

# lsvg -P vg00
Physical Volume   Mirror Pool      
hdisk2            DC01             
hdisk3            None             
hdisk4            DC02             
hdisk5            None             
#

Offensichtlich sind 2 Physical Volumes in der VG keinem Mirror Pool zugeordnet. Die freien Kapazitäten sind die folgenden:

# lsvg -p vg00
vg00:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk2            active            1271        55          00..00..00..00..55
hdisk3            active            1271        1171        255..154..254..254..254
hdisk4            active            1271        55          00..00..00..00..55
hdisk5            active            1271        71          00..00..00..00..71
#

In beiden Mirror Pools (DC01 hdisk2 und DC02 hdisk4) sind jeweils noch 55 PPs verfügbar. Angefordert wurden aber 64 PPs („-s 64“). Damit fehlen in jedem der beiden Mirror Pools 9 PPs für die Erweiterung, was in der Meldung „figure_min_alloc: FAIL: num_lps_to_file=9“ auch angegeben wird.

Nachdem die beiden „neuen“ Physical Volumes Mirror Pools zugeordnet wurden, ist die Dateisystem-Erweiterung erfolgreich:

# chpv -p DC01 hdisk3
# chpv -p DC02 hdisk5
#
#
# chfs -a size=+512M /fs01
Filesystem size changed to 20971520
Inlinelog size changed to 40 MB.
#

Es gibt sicher noch eine Reihe von weiteren Situationen in denen Dateisysteme nicht vergrößert werden können. Entscheidend ist, das ein Blick in den lvmt Log hoffentlich in vielen Fällen einen Hinweis auf die mögliche Ursache liefern kann.